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由 容 简介 


Docker 的 流行 激活 了 一 直 不 温 不 火 的 PaaS， 随 之 而 来 的 是 各 类 
Micro-PaaS 的 出 现 ，Kubernetes 是 其 中 最 具 代 表 性 的 一 员 ， 它 是 Google 
多 年 大 规模 容器 管理 技术 的 开源 版 本 。 越 来 越 多 的 企业 被 迫 面 对 互联 网 
规模 所 带 来 的 各 类 难题 ， 而 Kubernetes 以 其 优秀 的 理念 和 设计 正在 逐步 
形成 新 的 技术 标准 ， 对 于 任何 领域 的 运营 总 监 、 架 构 师 和 软件 工程 师 来 
说 ， 都 是 一 个 绝 佳 的 突破 机 会 。 本 书 以 理论 加 实战 的 模式 ， 结 合 大 量 案 
例 由 浅 入 深 地 讲解 了 Kubernetes 的 各 个 方面 ， 包 括 平台 染 构 、 基 础 核心 
功能 、 网 络 、 安 全 和 资源 管理 以 及 整个 生态 系统 的 组 成 ， 则 在 帮助 读者 
全 面 深入 地 掌握 Kubernetes+Docker 的 底层 技术 堆栈 。 
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Bits a EK PARE SIZ A, re AE Te HB EK 
数据 的 诞生 。 而 对 于 数据 中 心 的 需求 激活 了 云 计算 井喷 式 的 发 展 ， 一 时 
间 大 数据 和 云 计 算 成 为 各 个 企业 争夺 的 战略 高 地 。 





在 云 计算 领域 的 服务 模式 中 ，IaaSs 和 SaaSs 模 式 已 经 趋 于 成 熟 ， 因 此 
PaaS 就 成 了 全 球 各 大 IT 己 涉 和 初创 公司 的 焦点 ， 其 中 的 欧 争 异常 激烈 。 
大 量 的 PaaS 平 台 出 现 ， 又 很 快 被 淘汰 ， 整 个 行业 发 生 着 巨大 的 迭代 更 
蔡 。 正 所 谓 物 竞 天 择 ， 在 这 样 一 个 激荡 变化 的 背景 下 ， 以 Docker 为 代表 
的 容器 技术 脱颖而出 并 极速 发 热 ， 风 头 无 两 ， 大 多 数 主流 云 三 商 已 经 宣 
布 提供 对 Docker 及 其 生态 系统 的 文 持 。 容 器 技术 有 具备 融合 DevOps 的 敏 
捷 特 性 ， 给 云 计 算 市 场 特 别 是 PaaS 市 场 带 来 了 新 的 变革 力量 ， 
Kubernetes 就 是 新 一 轮 变革 中 产生 的 一 个 代表 性 产品 。 








Kubernetes 是 Google 开 源 的 容器 集群 管理 系统 ， 它 对 于 容器 运行 
时 、 编 排 、 和 常规 服务 都 抽象 设计 出 了 准确 完整 的 API， 并 以 此 建立 起 一 
个 开放 开源 的 系统 ， 符 合 企业 化 需求 ， 每 家 企业 都 可 以 以 此 搭建 出 自动 
化 和 标准 化 的 底层 平台 ， 以 优化 研发 和 运营 效 紊 。Kubernetes 可 以 说 是 
Google 借 助 着 容器 领域 的 爆发 ， 对 于 其 巳 大 规模 数据 中 心 管理 的 丰富 经 
验 的 一 次 实践 ， 则 在 建立 新 的 技术 业界 标准 。 











展望 未 来 ， 我 们 认为 将 有 更 多 的 企业 被 迫 面 对 互联 网 规模 所 带 来 的 
各 类 难题 ，Kubernetes 和 Docker 技 术 可 以 提供 应 对 这 些 挑 战 的 解雇 方 


案 。 而 随 着 更 多 企业 的 加 入 ， 会 有 更 多 的 人 以 协作 方式 构建 出 更 强大 的 
技术 堆栈 和 更 多 的 创新 成 果 ， 整 个 行业 将 瑚 着 更 好 的 方向 持续 迈进 ， 对 
此 我 们 乐观 其 成 。 


本 书 特 点 


本 书 采 用 的 是 理论 加 实战 的 模式 ， 结 合 大 量 案例 由 浅 入 深 讲 解 
Kubernetes 的 各 个 方面 ， 包 括 平台 架构 、 基 础 核心 功能 、 网 络 、 安 全 和 
资源 管理 ， 以 及 整个 生态 系统 的 组 成 。 技 术 信息 完全 来 源 于 Kubernetes 
开源 社区 的 文档 、 代 码 的 提炼 和 总 结 。 本 书 涉 及 的 Kubernetes 内 容 与 官 
方 最 新 版 本 同步 ， 包 含 最 新 版 本 的 所 有 新 特性 说 明 ， 并 且 因 为 
Kubernetes 同 Docker 深 度 集成 ， 所 以 本 书 也 会 前 述 Docker 相 关 的 技术 话 


题 。 
本 书 的 读者 对 象 


本 书 适 用 于 希望 学 习 和 使 用 Kubernetes 以 及 正在 寻找 管理 数据 中 心 
解决 方案 的 软件 工程 师 和 架构 师 ， 同 时 本 书 可 以 作为 Docker 的 高 级 延伸 
书籍 ， 用 于 搭建 基于 Kubernetes+Docker 的 Paas 平 台 ， 实 践 DevOps。 


本 书 的 组 织 结构 
本 书 在 组 织 结构 上 分 成 三 部 分 : Kubernetes 基 础 篇 、Kubernetes 高 级 
力 
构 和 核心 概念 ， 同 时 能 够 部 赦 和 使 用 Kubernetes 完 成 基本 功能 操作 。 高 
级 篇 将 深入 讲解 Kubernetes 的 网 络 、 安 全 和 资源 管理 等 话题 ， 帮 助 读 者 


掌握 管理 Kubernetes 的 能 力 。 和 生态 篇 则 介绍 与 Kubernetes 密 切 相关 的 开源 
软件 ， 包 括 CoreOS、Etcd 和 Mesos， 使 读者 对 于 Kubernetes 生 态 系统 有 


全 面 的 了 解 。 
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第 1 章 
Kubernetes 介 绍 


Kubernetes 可 以 说 是 云 计算 PaaS 领 域 的 集大成 者 ， 它 借助 了 最 好 的 
帮助 ， 并 且 在 最 适当 的 时 间 推 出 ， 从 而 得 到 了 最 多 的 关注 。 本 章 自 先 从 
整个 行业 背景 介绍 入 手 ， 介 绍 Kubernetes 诞 生 的 前 因 ， 并 阐述 Kubernetes 
的 优势 和 发 展 历程 ， 最 后 说 明 Kubernetes 中 的 基本 概念 ， 帮 助 读 者 对 
Kubernetes 有 一 个 初步 但 全 面 的 认识 。 





1.1 为 什么 会 有 Kubernetes 


1.1.1 云 计 算 大 潮 





云 计 算 (Cloud Computing) 作为 一 个 新 兴 领 域 ， 它 是 多 种 技术 混合 
演进 的 结果 ， 在 许多 大 公司 和 初创 企业 的 共同 推动 下 ， 发 展 极为 迅速 并 
且 持 续 火 热 ， 带 来 了 新 一 轮 的 IT 变 单 。 云 计算 带 给 企业 的 创新 能 力 和 发 
展 空间 是 不 可 想象 的 ， 我 们 所 有 人 都 正 处 于 云 计 算 大 潮 中 。 








云 计算 从 狭义 上 讲 ， 指 IT 基础 设施 的 交付 和 使 用 模式 ， 即 通过 网 络 
以 按 霸 、 易 扩展 的 方式 获取 所 需 资 源 。 广 义 上 则 指 服务 的 交付 和 使 用 模 
式 ， 通 过 网 络 以 按 需 、 易 扩展 的 方式 获取 所 需 服 务 。 提 供 资源 的 网 络 被 
形象 地 比喻 成 “ 云 "， 其 计算 能 力 通 党 是 由 分 布 式 的 大 规模 集群 和 虚拟 化 
技术 提供 的 。 而 “ 云 ? 中 的 计算 资源 在 用 户 看 来 是 可 以 扩展 ， 并 且 可 以 随 




















时 获取 、 按 需 使 用 的 。 


云 计 算 彻底 改变 了 人 们 对 计算 资源 的 使 用 方式 ， 有 一 个 形象 的 比喻 
说 明了 云 计算 革命 性 的 影响 :“ 云 ?好 比 一 个 发 电 广 ， 互 联网 好 比 是 输电 
线路 ， 只 不 过 这 个 发 电 广 对 外 提供 的 是 IT 服务 ， 这 种 服务 将 通过 互联 网 
传输 到 干 家 万 户 。 云 计算 实现 了 计算 资源 从 单 台 发 电机 供电 模式 向 电 广 
集中 供电 模式 的 转变 。 








业界 根据 云 计 算 提 供 服 务 资 源 的 类 型 将 其 划分 为 三 大 类 : 基础 设施 
即 服务 (Infrastructure-as-a-Service，IaaS) 、 平 台 即 服务 (Platform-as- 
a-Service, Paas) 和 软件 即 服务 (Software-as-a-Service, SaaS) ， 如 图 
1-1 所 示 。 
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图 1-1 云 计算 的 三 层 架 构 


。 基 础 设施 即 服务 


基础 设施 即 服务 〈IaaS) 通过 虚拟 化 和 分 布 式 存储 等 技术 ， 实 现 了 
对 包括 服务 器 、 存 储 设备 、 网 络 设备 等 各 种 物理 资源 的 抽象 ， 从 而 形成 
了 一 个 可 扩展 、 可 按 需 分 配 的 虚拟 资源 池 。IaaS 对 外 呈现 的 服务 是 各 种 
基础 设置 ， 例 如 虚拟 机 、 磁 盘 以 及 主机 互联 而 成 的 网 络 ， 这 些 虚 拟 机 中 
可 以 运行 Windows 系 统 ， 也 可 以 运行 Linux 系 统 ， 在 用 户 看 来 ， 它 与 一 
台 真 实 的 物理 机 是 没有 区 别 的 。 目 前 最 具 代 表 性 的 IaaS 产 品 有 Amazon 
AWS， 其 提供 了 虚拟 机 EC2 和 云 存储 S3 等 服务 。 














。 平 台 即 服务 





平台 即 服务 (PaaS〉 为 开发 者 提供 了 应 用 的 开发 环境 和 运行 环境 ， 
将 开发 者 从 烦琐 的 I 环 境 管理 中 解放 出 来 。 上 自动化 应 用 的 部 普 和 运 维 ， 
使 开发 者 能 够 集中 精力 于 应 用 业务 开发 ， 极 大 地 提升 了 应 用 的 开发 效 
率 。 可 以 说 ，PaaSs 主 要 面 问 的 是 软件 专业 人 员 ，Google 的 GAE 是 PaaSs 的 
鼻祖 ， 而 Kubernetes 可 以 说 是 在 Paas 的 定义 范畴 内 。 





。 软 件 即 服务 


软件 即 服务 (Saas) 主要 面向 使 用 软件 的 终端 用 户 。 一 般 来 说 ， 
SaaS 将 软件 功能 以 特定 的 接口 形式 发 布 ， 终 端 用 户 通 过 网 络 浏览 器 就 可 
以 使 用 软件 功能 。 终 端 用 户 将 只 关注 软件 业务 的 使 用 ， 除 此 之 外 的 工 
作 ， 如 软件 的 升级 和 云端 实现 ， 对 终端 用 户 来 说 都 是 透明 的 。SaaS 是 应 
用 最 广 的 云 计 算 模式 ， 比 如 我 们 在 线 使 用 的 邮箱 系统 和 各 种 管理 系统 都 
可 以 认为 是 SaaS 的 范畴 。 





综 上 所 述 ， 可 以 简单 地 概括 为 SaaS 通 过 网 络 运行 ， 为 最 终 用 户 提 
供应 用 服务 ，PaaS 是 一 套 工具 服务 ， 可 以 为 编码 和 部 普 应 用 程序 提供 快 
速 、 高 效 的 服务 ，IaaS 包 括 硬件 和 软件 ， 例 如 服务 器 、 存 储 、 网 络 和 操 
作 系 统 。 


与 SaaS 相 比 ，PaaS 和 IaaS 的 概念 和 技术 相对 较 新 ， 图 1-2 比 较 了 传统 
IT、IaaS 和 PaaS。 假 设 现在 要 上 线 一 项 新 业务 ， 传 统 IT 的 做 法 就 是 自 下 
而 上 地 搭建 部 署 、 购 置 人 硬件、 配置 网 络 、 安 装 操作 系统 、 部 署 中 间 件 系 
统 ， 到 最 后 业务 上 线 。 使 用 Iaas 的 客户 则 无 顷 关 心 操 作 系 统 以 下 的 实 
现 ，Paas 更 进一步 封装 操作 系统 、 中 间 件 和 运行 时 ， 形 成 标准 式 的 业务 
发 布 平台 ， 提 供 智 能 化 运 维 能 力 。 这 是 一 种 递 进 式 的 演化 ， 一 步 一 步 地 
将 技术 栈 分 层 分 级 ， 将 资源 进行 整合 管理 ， 可 极 大 提高 效率 。 
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图 1-2 传统 IT、l1aaS 和 PaaS 的 比较 





正 是 由 于 云 计算 的 强大 优势 ， 越 来 越 多 的 公司 进入 这 波 潮 流 中 ， 形 
成 了 百 家 齐 放 的 场面 。 在 云 计算 的 不 同 导 次， 在 各 个 行业 的 不 同 领域 ， 
都 涌现 出 一 大 批 云 计 算 产 品 ， 整 个 云 计算 市 场 正 在 高 速 发 展 。 











1.1.2 不 温 不 火 的 PaaS 


在 SaaSs 的 成 熟 和 IaaS 的 高 速 用 展 催 生 下 ， 特 别 是 在 Amazon、 
Google、Salesforce、Microsoft 等 公司 的 推动 下 ，PaaS 得 到 了 长 足 的 发 
展 ， 越 来 越 多 的 人 开始 谈论 和 关注 PaaS， 包 括 运 营 商 、 互 联网 巨头 、 传 
统 IT 厂 商 、 咨 询 和 集成 两 、IT 技 术 媒 体 等。 但 是 PaaS 的 发 展 可 以 说 是 一 
波 三 折 ， 可 以 分 为 三 个 阶段 。 








。 第 一 代 PaaS 


比如 GAE (Google App Engine) ~ SAE (Sina App Engine) 。 这 是 
早期 的 PaaS， 当 时 并 没有 PaaS 这 个 概念 ， 现 在 看 来 是 包含 在 PaaS 范 围 内 
的 。 





。 第 二 代 PaaS 


比如 Cloud Foundry、Openshift。 这 是 各 大 IaaS (如 Amazon AWS, 
OpenStack) 流行 之 后 ， 顺 势 推出 的 PaaSs， 并 且 发 展 迅 速 。 其 中 Cloud 
Foundry 是 VMware 于 2011 年 推出 的 业界 第 一 个 开源 PaaS 云 平台 ， 后 来 分 
拆 出 Pivotal 公 司 进 行 接管 ，2014 创 立 Cloud Foundry 基 金 会 进行 运作 。 技 
术 和 模式 相 比 第 一 代 PaaS 都 有 一 定 的 提高 ， 在 云 计 算 大 潮 中 引领 了 PaaS 
的 发 展 ， 一 时 成 为 PaaS 的 代表 。 华 为 云 、IBM BlueMix、HP Cloud 和 
Dell 云 服务 都 采用 了 Cloud Foundry 作 为 基础 。 





但 是 这 个 阶段 的 Paas 不 管 是 在 市 场 份 额 ， 还 是 提升 速度 上 都 处 于 弱 
势 ， 用 户 对 PaaSs 的 兴趣 似乎 也 不 大 。 同 时 ， 随 着 各 种 云 服务 之 间 界 限 的 
逐步 模糊 ， 一 部 分 人 甚至 认为 PaaS 将 最 终 消 亡 或 成 为 IaaS 或 者 SaaS 的 一 


个 功能 ，PaaS 处 于 不 温 不 火 的 尴 罚 位 置 。 
。 第 三 代 PaaS 


在 Docker 火 爆 之 后 ， 利 用 Docker 的 特性 构建 出 许多 PaaS， 比 如 
Kubernetes。 这 些 PaaS 更 加 灵活 ， 更 加 适应 企业 ， 逐 渐 成 为 PaaS 的 主 
IJ 


1.1.3 Dockerfy wiz 


Docker 是 一 种 Linux 容 器 工具 集 ， 它 是 为 构建 (Build) 、 交 付 
(Ship) 和 运行 (Run) 分 布 式 应 用 而 设计 的 。 作 为 DotCloud 公 司 的 开 
源 项 目 ， 其 首发 版 本 的 时 间 是 2013 年 3 月 。 该 项目 很 快 就 受到 欢迎 ， 这 
也 使 得 DotCloud 公 司 将 其 品牌 改 为 Docker， 并 最 终 将 其 原 有 的 PaaS 业 务 
出 售 而 专注 在 Docker 上 ，Docker 完 成 了 华丽 的 逆 袭 。 








Docker 设 计 理 论 来 目 集装箱 ， 假 设 交 付 运 行 环境 如 同 海运 ， 操 作 系 
统 如 同一 艘 货轮， 每 一 个 在 操作 系统 基础 上 运行 的 软件 都 如 同一 个 集 装 
箱 ， 用 户 可 以 通过 标准 化 手段 自由 组 装运 行 环境 ， 同 时 集装箱 的 内 容 可 
以 由 用 户 自 定义 ， 也 可 以 由 专业 人 员 制 造 。 这 样 ， 交 付 一 个 软件 ， 就 是 
一 系列 标准 化 组 件 的 集合 的 交付 ， 如 同 搭建 乐高 积木 ， 用 户 只 需 选 择 合 
适 的 积 森 组合， 并 且 在 顶端 署 上 自己 的 名 字 ， 最 后 这 个 标准 化 组 件 束 是 
用 户 的 应 用 。 





基于 这 个 理念 ， 在 技术 实现 上 ，Docker 利 用 容器 (Container) 来 实 


现 类 似 虚 拟 机 的 功能 ， 从 而 利用 更 加 节省 的 人 硬件 资源 提供 给 用 户 更 多 的 
计算 资源 。 同 虚拟 机 的 方式 不 同 ， 容 器 并 不 是 一 套 人 硬件 虚拟 化 方法 ， 也 
无 法 归属 到 全 虚拟 化 、 部 分 虚拟 化 和 半 虚 拟 化 中 的 任意 一 个 ， 而 是 一 个 
操作 系统 级 虚拟 化 方法 。 


Docker 容 堪 技 术 的 优势 有 以 下 几 点 。 


。 一 次 构建 ， 到 处 运行 





当 将 容 需 固化 成 镜像 后 ， 可 以 快速 地 加 载 到 任何 环境 中 部 闭 运 
行 。 而 构建 出 来 的 镜像 打包 了 应 用 运行 所 需 的 程序 、 依 赖 和 运行 环 
境 ， 这 和 古 一 个 完 束 可 用 的 应 用 集装箱 ， 在 任何 环境 下 都 能 保证 环境 
的 一 致 性 。 











。 容 器 的 快速 轻 量 
容器 的 启动 、 停 止 和 销毁 都 是 以 秒 或 毫秒 为 单位 的 ， 并 且 相 比 
传统 的 虚拟 化 技术 ， 使 用 容器 在 CPU、 内 存 ， 网 络 1/O 等 资源 上 的 
性 能 损耗 都 有 同样 水 平 甚至 更 优 的 表现 。 


© 完整 的 生态 链 


容器 技术 并 不 是 Docker 首 创 ， 但 是 以 往 的 容器 实现 只 关注 于 如 
何 运行 ， 而 Docker 站 在 巨人 的 肩膀 上 进行 了 整合 和 创新 ， 特 别 是 


Docker 镜 像 的 设计 ， 完 美 地 为 容 右 从 构建 、 交 付 到 运行 提供 了 完整 
的 生态 链 支 持 。 


Docker 1.0 在 2014 年 6 月 发 布 ， 而 且 延 续 了 之 前 每 月 发 布 一 个 版 本 的 
节奏 。 其 1.0 版 本 标志 着 Docker 公 司 认为 Docker 平 台 已 经 足够 成 熟 ， 并 可 
以 被 应 用 到 生产 环境 中 。 每 月 的 版 本 更 新 显示 出 该 项 目 正 在 快速 友 展 ， 
比如 增加 新 的 特性 ， 解 决 发 现 的 问题 等 。 








Docker 的 持续 火热 是 有 着 坚实 的 基础 来 文 撑 的 。Docker 吸 引 了 业界 
众多 知名 大 牌 三 家 的 文 持 ， 其 中 包括 Amazon、Canonical、 
CenturyLink、Google、IBM、Microsoft、New Relic, Pivotal, Red Hat 
和 VMware， 这 使 得 只 要 在 有 Linux 的 地 方 ，Docker 束 几乎 随处 可 用 。 除 
了 这 些 大 三 ， 许 多 初创 企业 也 围绕 着 Docker 来 发 展 ， 或 是 将 他 们 的 发 展 
方向 和 Docker 更 好 地 结合 起 来 。 所 有 这 些 合作 伙 伴 都 丝 动 着 Docker 核 心 
项 目 和 周边 生态 系统 的 快速 发 展 。 








更 重要 的 是 Docker 的 流行 和 标准 化 ， 激 活 了 一 直 不 温 不 火 的 PaaS， 
随 之 而 来 的 是 各 类 Micro-PaaS 的 出 现 ，Kubernetes 是 其 中 最 具 代 表 性 的 


1.2 Kubernetes 是 什么 


Kubernetes 是 Google 开 源 的 容器 集群 管理 系统 。 它 构建 在 Docker 技 
术 之 上 ， 为 容器 化 的 应 用 提供 资源 调度 、 部 署 运 行 、 服 务 发 现 、 扩 容 缩 
容 等 一 整套 功能 ， 本 质 上 可 看 作 是 基于 容器 技术 的 Micro-PaaSs 平 台 ， 即 
第 三 代 PaaS 的 代表 性 项 目 。 








Google 从 2004 年 起 就 已 经 开始 使 用 容器 技术 了 ， 于 2006 年 发 布 了 
Cgroup， 而 且 内 部 开发 了 强大 的 集群 资源 管理 平台 Borg 和 Omega， 这 些 
都 已 经 广泛 使 用 在 Google 的 各 个 基础 设施 中 ， 而 Kubernetes 的 灵感 来 源 
于 Google 的 内 部 Borg 系 统 ， 更 是 吸收 了 包括 Omega 在 内 的 容器 管理 器 的 
经 验 和 教训 。 


Kubernetes， 古 希腊 语 是 能 手 的 意思 ， 也 是 Cyber 的 词 源 ， 
Kubernetes 利 用 Google 在 容器 技术 上 的 实践 经 验 和 技术 积累 ， 同 时 吸取 
Docker 社 区 的 最 佳 实践 ， 已 经 成 为 云 计 算 服 务 的 舵手 。 





Kubernetes 有 着 如 下 的 优秀 特性 。 
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Kubernetes 可 以 说 是 同 Docker 一 起 发 展 起 来 的 ， 深 度 集 成 了 
Docker， 天 然 适应 容器 的 特点 ， 设 计 出 强大 的 容 右 编排 能 力 ， 比 如 
容器 组 合 、 标 签 选 择 和 服务 发 现 等 ， 可 以 满足 企业 级 需求 。 


。 轻 量 级 


Kubernetes 遵 循 微服 务 架 构 理论 ， 整 个 系统 划分 出 各 个 功能 独 
立 的 组 件 ， 组 件 之 间 边 界 清晰 ， 部 署 简单 ， 可 以 轻易 地 运行 在 各 种 
系统 和 环境 中 。 同 时 ，Kubernetes 中 的 许多 功能 都 实现 了 插件 化 ， 
可 以 非常 方便 地 进行 扩展 和 替换 。 
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Kubernetes 顺 应 了 开放 开源 的 趋势 ， 吸 引 了 大 批 开 发 者 和 公司 
参与 其 中 ， 协 同 工 作 共同 构建 生态 圈 。 同 时 ，Kubernetes 同 
OpenStack、Docker 等 开源 社区 积极 合作 、 共 同 发 展 ， 企 业 和 个 人 
都 可 以 参与 其 中 并 获 益 。 


1.3 ”Kubernetes 的 发 展 历 史 


Kubernetes 自 推出 后 迅速 得 到 关注 和 参与 ，2015 年 7 月 经 过 400 多 位 
页 献 者 一 年 的 努力 ， 多 达 14,000 次 代码 提交 ，Google 正 式 对 外 发 布 了 
Kubernetes v1.0， 意 味 着 这 个 开源 容器 编排 系统 可 以 正式 在 生产 环境 中 
使 用 。 与 此 同时 ， 谷 歌 联合 Linux 基 金 会 及 其 他 合作 伙伴 共同 成 立 了 
CNCF2£<4=4 (Cloud Native Computing Foundation) ， 并 将 Kubernetes 作 
为 首 个 编 入 CNCF 基 金 会 管理 体系 的 开源 项 目 ， 助 力 容 器 技术 生态 的 发 
展 进步 。 


Kubernetes 的 发 展 里 程 碑 如 下 所 示 。 
。2014 年 6 月 : 谷歌 宣布 Kubernetes 开 源 。 


2014 年 7 月 : Microsoft. Red Hat. IBM, Docker. CoreOS, 
Mesosphere 和 Saltstack 加 入 Kubernetes 。 


2014 年 8 月 : Mesosphere 宣 布 将 Kubernetes 作 为 框架 整合 到 
Mesosphere 生 态 系统 中 ， 用 于 Docker 容 器 集群 的 调度 、 部 署 和 管理 。 


。 2014 年 8 月 : VMware 加 入 Kubernetes 社 区 ，Google 产 品 经 理 Craig 
Mcluckie 公 开 表 示 ，VMware 将 会 帮助 Kubernetes 实 现 利 用 虚拟 化 来 保证 
物理 主机 安全 的 功能 模式 。 


。2014 年 11 月 : HP 加 入 Kubernetes 社 区 。 


。2014 年 11 月 : Google 容 器 引擎 Alpha 启 动 ， 谷 歌 宣布 GCE 支 持 容 器 
及 服务 ， 并 以 Kubernetes 为 构架 。 


。 2015 年 1 月 : Google 和 Mirantis 及 伙伴 将 Kubernetes 引 入 
OpenStack， 开 发 者 可 以 在 OpenStack 上 部 署 运行 Kubernetes 应 用 。 


。 2015 年 4 月 : Google 和 CoreOS 联 合 发 布 Tectonic， 它 将 Kubernetes 
和 CoreOS 软 件 栈 整 合 在 了 一 起 。 


。2015 年 5 月 : Intel 加 入 Kubernetes 社 区 ， 宣 布 将 合作 加 速 Tectonic 软 
件 栈 的 发 展 进度 。 


。2015 年 6 月 : Google 容 器 引擎 进入 beta 版 。 


。2015 年 7 月 : Google 正 式 加 入 OpenStack 基 金 会 ，Kubermetes 产 品 经 
{Craig McLuckie 宣 布 Google 将 成 为 OpenStack 基 金 会 的 发 起 人 之 一 ， 
Google 将 把 他 的 容器 计算 的 专家 技术 带 入 OpenStack， 以 提高 公有 云 和 
私有 云 的 互 用 性 。 


。2015 年 7 月 : Kubernetes v1.0 正 式 发 布 。 


1.4 Kubernetes 的 核心 概念 


1.4.1 Pod 


Pod 是 若干 相关 容器 的 组 合 ，Pod 包 含 的 容器 运行 在 同一 台 宿 主机 
上 ， 这 些 容器 使 用 相同 的 网 络 命名 空间 、IP 地 址 和 端口 ， 相 互 之 间 能 通 
过 localhost 来 发 现 和 通信 。 男 外 ， 这 些 容器 还 可 共享 一 块 存 储 卷 空间 。 
在 Kubernetes 中 创建 、 调 度 和 管理 的 最 小 单位 是 Pod， 而 不 是 容器 ，Pod 
通过 提供 更 高 层次 的 抽象 ， 提 供 了 更 加 灵活 的 部 署 和 管理 模式 。 











1.4.2 Replication Controller 


Replication Controller 用 来 控制 管理 Pod 副 本 (Replica, BARK ASE 
例 ) ，Replication Controller 确 保 任何 时 候 Kubernetes 集 群 中 有 指定 数量 
的 Pod 副 本 在 运行 。 如 果 少 于 指定 数量 的 Pod 副 本 ，Replication Controller 
会 启动 新 的 Pod 副 本 ， 反 之 会 杀 死 多 余 的 副本 以 保证 数量 不 变 。 另 外 ， 
Replication Controller 是 弹性 伸缩 、 滚 动 升级 的 实现 核心 。 


1.4.3 Service 


Service 是 真实 应 用 服务 的 抽象 ， 定 义 了 Pod 的 逻辑 集合 和 访问 这 个 
Pod 和 集合 的 策略 。Service 将 代理 Pod 对 外 表现 为 一 个 单一 访问 接口 ， 外 部 
不 需要 了 人 解 后 端 Pod 如 何 运行 ， 这 给 扩展 和 维护 带 来 很 多 好 处 ， 提 供 了 
一 套 简 化 的 服务 代理 和 发 现 机 制 。 





1.4.4 Label 


Label 是 用 于 区 分 Pod、Service、Replication ”Controller 的 Key/Value 
对 ， 实 际 上 ，Kubernetes 中 的 任意 API 对 象 都 可 以 通过 Label 进 行 标识 。 
每 个 API 对 象 可 以 有 多 个 Label， 但 是 每 个 Label 的 Key 只 能 对 应 一 个 
Value。Label 是 Service 和 Replication Controller 运 行 的 基础 ， 它 们 都 通过 
Label 来 关联 Pod， 相 比 于 强 绑 定 模型 ， 这 是 一 种 非常 好 的 松 耘 合 关 系 。 





1.4.5 Node 


Kubernetes 属 于 主 从 分 布 式 集群 架构 ，Kubernetes Node (HRA 
Node， 早 期 版 本 叫 作 Minion〉 运行 并 管理 容器 。Node 作 为 Kubernetes 的 
操作 单元 ， 用 来 分 配给 Pod〈 或 者 说 容器 ) 进行 绑 定 ，Pod 最 终 运行 在 
Node 上 ，Node 可 以 认为 是 Pod 的 答 主 机 。 


第 2 章 
Kubernetes 上 的 架构 和 部 闭 


Kubernetes 遵 循 微服 务 架 构 理 论 ， 整 个 系统 划分 出 各 个 功能 独立 的 
组 件 ， 组 件 之 间 边 界 清 上 晰 ， 部 署 简单 ， 可 以 轻易 地 运行 在 各 种 系统 和 环 
境 中 。 本 章 将 首先 介绍 Kubernetes 的 架构 和 各 个 组 件 的 功能 ， 然 后 详细 
说 明 如 何 从 头 开始 部 署 一 套 完整 的 Kubernetes 运 行 环 境 ， 包 括 Kubernetes 
提供 的 各 种 扩展 插件 〈Cluster Add-on) 的 安装 方式 。 


2.1 Kubernetes 的 架构 和 组 件 











Kubernetes 属 于 主 从 分 布 式 架构 ， 节 点 在 角色 上 分 为 Master 和 
Node， 如 图 2-1 所 示 。 









































































































































































































































图 2-1 Kubernetes 的 架构 


Kubernetes 使 用 Etcd 作 为 存储 中 间 件 ，Etcd 是 一 个 高 可 用 的 键 值 存 
储 系 统 ， 灵 感 来 自 于 ZooKeeper 和 Doozer， 通 过 Raft 一 致 性 算法 处 理 日 志 
复制 以 保证 强 一 致 性 。Kubernetes 使 用 Etcd 作 为 系统 的 配置 存储 中 心 ， 
Kubernetes 中 的 重要 数据 都 是 持久 化 在 Etcd 中 的 ， 这 使 得 Kubernetes 架 构 
的 各 个 组 件 属于 无 状态 ， 可 以 更 简单 地 实施 分 布 式 集群 部 辕 。 


Kubernetes ” Master 作为 控制 节点 ， 调 度 管理 整个 系统 ， 包 含 以 下 组 
件 。 


。Kubernetes API Server: 作为 Kubernetes 系 统 的 入 口 ， 其 封装 了 核 
心 对 象 的 增删 改 查 操作 ， 以 REST API 接 口 方式 提供 给 外 部 客户 和 内 部 
组 件 调用 。 它 维护 的 REST 对 象 将 持久 化 到 Etcd 中 。 








。Kubernetes Scheduler: 负责 集群 的 资源 调度 ， 为 新 建 的 Pod 分 配 机 





项 。 这 部 分 工作 分 出 来 变 成 一 个 组 件 ， 意 味 厦 可 以 很 方便 地 将 换 成 其 他 
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Kubernetes Controller Manager: 负责 执行 各 种 控制 器 ， 目 前 已 经 
实现 很 多 控制 器 来 保证 Kubernetes 的 正常 运行 ， 主 要 包含 的 控制 器 如 表 
2-1 所 示 。 


表 2-1 Kubernetes 控制 器 


Replication Controller 管理 维护 Replication Controller， 关 联 Replication Controller 和 Pod， 
保证 Replication Controller 定 义 的 副本 数量 与 实际 运行 Pod 的 数量 是 
- 致 的 
Node Controller 管理 维护 Node， 定 期 检查 Node 的 健康 状态 ， 标 识 出 失效 的 Node 
Namespace Controller 管理 维护 Namespace， 定 期 清理 无 效 的 Namespace， 包 括 Namespace 
下 的 API 对 象 ， 像 Pod、Service 和 Secret 等 
Service Controller 管理 维护 Service， 为 LoadBalancer 类 型 的 Service 创 建 管理 负载 均衡 
器 
Endpoints Controller 管理 维护 Endpoints， 关 联 Service 和 Pod， 创 建 Endpoints 作 为 Service 
的 后 端 ， 当 Pod 发 生变 化 时 ， 实 时 刷新 Endpoints 
Service Account Controller 管理 维护 Service Account， 为 每 个 Namespace 创 建 默认 Service 
Account， 同 时 为 Service Account 创 建 Service Account Secret 











Persistent Volume Controller 管理 维护 Persistent Volume 和 Persistent Volume Claim， 为 新 的 
Persistent Volume Claim 分 配 Persistent Volume 进 行 绑 定 ， 为 释放 的 
Persistent Volume 执 行 清理 回收 

Daemon Set Controller 管理 维护 Daemon Set， 人 负责 创建 Daemon Pod， 保 证 指定 的 Node 上 
正常 运行 Daemon Pod 





Deployment Controller 管理 维护 Deployment， 关 联 Deployment 和 Replication Controller， 保 
证 运行 指定 数目 的 Pod。 当 Deployment 更 新 时 ,控制 实现 Replication 
Controller 和 Pod 的 更 新 

Job Controller 管理 维护 Job， 为 Job 创 建 一 次 性 任务 Pod， 保 证 完成 Job 指 定 完 成 的 
任务 数目 

Pod Autoscaler Controller 实现 Pod 的 自动 伸缩 ， 定 时 获取 监控 数据 ， 进 行 策略 匹配 ， 当 满足 
条 件 时 执行 Pod 的 伸缩 动作 














Kubernetes Node 是 运行 节点 ， 用 于 运行 管理 业务 的 容 姻 ， 包 含 以 下 
组 件 。 


。 Kubelet: 负责 管控 容器 ，Kubelet 会 从 Kubernetes API Server 接 收 
Pod 的 创建 请 求 ， 启 动 和 停止 容器 ， 监 控 容 器 运行 状态 并 汇报 给 





Kubernetes API Server。 


e Kubernetes Proxy: 负责 为 Pod 创 建 代理 服务 ，Kubernetes Proxy 
从 Kubernetes API Server 获 取 所 有 的 Service， 并 根据 Service 信 息 创 建 代 
理 服务 ， 实 现 Service 到 Pod 的 请 求 路 由 和 转发 ， 从 而 实现 Kubernetes 层 级 
的 虚拟 转发 网 络 。 








Docker: Kubernetes ”Node 是 容器 运行 节点 ， 需 要 运行 Docker 服 
务 ， 目 前 Kubernetes 也 支持 Rocket， 这 是 一 款 CoreOS 开 发 的 类 Docker 的 
开源 容器 引擎 ， 本 书 只 说 明 Docker。 


2.2 部署 Kubernetes 


Kubernetes 能 够 运行 在 各 个 平台 上 ， 包 括 物 理 机 、 虚 拟 机 和 云 平 
人 台 。 在 部 署 方式 上 ，Kubernetes 可 以 在 生产 环境 中 大 规模 地 进行 分 布 式 
部 闭 ， 也 可 以 简单 地 运行 在 单机 中 以 用 于 测试 开发 ， 我 们 可 以 根据 不 同 
的 需求 搭建 不 同 的 Kubernetes 运 行 环境 。 





Kubernetes 官 方 和 社区 针对 不 同系 统 和 平台 提供 了 自动 化 部 署 肢 
本 ， 具 体 情 况 如 表 2-2 所 示 。 


表 2-2 Kubernetes 部 署 支持 
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接 下 来 我 们 将 详细 说 明 Kubernetes 的 部 署 步 又， 同时 也 会 涉 
Kubernetes 的 一 些 概念 ， 可 以 进一步 帮助 读者 理解 Kubernetes 的 架构 和 原 
理 。 


2.2.1 环境 准备 


Kubernetes 是 一 个 分 布 式 架 构 ， 可 灵活 地 进行 安装 部 署 ， 可 以 部 署 
在 单机 ， 也 可 以 分 布 式 部 署 。 机 器 可 以 是 物理 机 ， 也 可 以 是 虚拟 机 ， 但 
是 需要 运行 Linux (x86_64) 操作 系统 ， 至 少 1 核 CPU 和 1GB 内 存 。 


本 书 准备 了 4 台 虚 拟 机 (CentOS 7.0 系统 ) 用 于 部 署 Kubernetes 运 行 
环境 ， 包 括 一 个 Etcd、 一 个 Kubernetes Master 和 三 个 Kubernetes Node, 
如 表 2-3 所 示 。 


表 2-3 Kubernetes 运行 环境 


节点 主机 名 IP 
Etcd etcd 192.168.3.145 
Kubernetes Master kube-master 192.168.3.146 











Kubernetes Node 1 kube-node-1 192.168.3.147 
Kubernetes Node 2 kube-node-2 192.168.3.148 
Kubernetes Node 3 kube-node-3 192.168.3.149 

















使 用 的 各 种 软件 版 本 信息 如 表 2-4 所 示 。 


表 2-4 软件 版 本 


软件 
Kubernetes 
Docker 
Etcd 














Flannel 








Open vSwitch 


提示 


本 书后 续 的 实践 操作 都 在 此 套 环境 中 运行 。 





2.2.2 ”运行 Etcd 


Kubernetes 依 赖 于 Etcd， 需 要 先 部 署 Etcd， 可 以 从 Github 上 下 载 指定 
版 本 的 Etcd 发 布 包 : 


wget https://github.com/coreos/etcd/releases/download/v2.2.0/et 
tar xzvf etcd-v2.2.0-linux-amd64. tar.gz 
cd etcd-v2.2.0-linux-amd64 


cp etcd /usr/bin/etcd 


fF A Ff Ff fF 


cp etcdctl /usr/bin/etcdctl 


运行 Etcd: 


$ etcd -name etcd \ 

-data-dir /var/lib/etcd \ 

-listen-client-urls http://0.0.0.0:2379, http://0.0.0.0:4001 \ 
-advertise-client-urls http://0.0.0.0:2379, http://0.0.0.0:4001 \ 
>> /var/log/etcd.log 2>&1 & 





Etcd 运 行 后 可 以 查询 其 健康 状态 : 


$ etcdctl -C http://etcd:4001 cluster-health 
member ce2a822cea30bfca is healthy: got healthy result from http: 


cluster is healthy 


2.2.3 ”获取 Kubernetes 发 布 包 


Kubernetes 发 布 包 可 以 从 Github 上 下 载 ， 本 书 使 用 的 是 Kubernetes 
V1.1.1 版 本 : 


$ wget https://github.com/kubernetes/kubernetes/releases/download 


$tar zxvf kubernetes.tar.gz 
Kubernetes 发 布 包 中 包含 如 下 内 容 。 
e cluster: Kubernetes 上 自动 化 部 署 脚 本 。 
。contrib: Kubernetes 非 必需 程序 。 
。examples: Kubernetes 示 例 配置 文件 。 
。docs: Kubernetes 文 档 。 
。platforms: Kubernetes 的 命令 行 工 具 kubectl。 
。server: Kubernetes 组 件 。 
。third_party: 第 三 方程 序 。 


Kubernetes 发 布 包 中 的 server/kubernetes-server-linux-amd64.tar.gz 包 
含 各 个 组 件 的 可 执行 程序 ， 将 这 些 可 执行 程序 复制 到 Linux 系 统 目 
录 /use/bin/ 下 : 








$ cd kubernetes/server 
$ tar zxvf kubernetes-server-linux-amd64.tar.gz 
$ cd kubernetes/server/bin/ 


$ find ./ -perm 755 | xargs -i cp {} /usr/bin/ 


2.2.4 运行 Kubernetes Master 组 件 








在 Kubernetes Master 上 需要 运行 以 下 组 件 : 
e Kubernetes API Server 

e Kubernetes Controller Manager 

e Kubernetes Scheduler 

e Kubernetes Proxy 〈 可 选 ) 

Kubernetes API Server 


运行 Kubernetes API Server: 


$ kube-apiserver \ 

--logtostderr=true --v=0 \ 
--etcd_servers=http://etcd:4001 \ 
--insecure-bind-address=0.0.0.0 --insecure-port=8080 \ 
--service-cluster-ip-range=10.254.0.0/16 \ 


>> /var/log/kube-apiserver.log 2>&1 & 


Kubernetes Controller Manager 


1847 Kubernetes Controller Manager: 


$ kube-controller-manager \ 
--logtostderr=true --v=0 \ 


--master=http://kube-master:8080 \ 


>> /var/log/kube-controller-manager.log 2>&1 & 


Kubernetes Scheduler 


运行 Kubernetes Scheduler: 


$ kube-scheduler \ 
--logtostderr=true --v=0 \ 
--master=http://kube-master:8080 \ 


>> /var/log/kube-scheduler.log 2>&1 & 


Kubernetes Proxy 


运行 Kubernetes Proxy: 


$ kube-proxy \ 

--logtostderr=true --v=0 \ 
--api_servers=http://kube-master:8080 \ 
>> /var/log/kube-proxy.log 2>&1 & 


2.2.5 ”运行 Kubernetes Node 组 件 








Kubernetes Node 上 需要 运行 以 下 组 件 : 
。 Docker 
e Kubelet 


e Kubernetes Proxy 


Docker 


Docker 官 方 社区 提供 各 个 平台 的 安装 方法 〈 可 参考 
http://docs.docker.com/installation/) ， 很 多 Linux 发 行 版 都 陆续 对 Docker 
进行 了 文 持 ， 可 以 使 用 以 下 方式 快速 安装 Docker: 


$ curl -SSL https://get.docker.com/ | sh 


提示 


1. Docker 要 求 Linux 64 系 统 ， 并 且 内 核 至 少 3.10 版 本 以 上 。 


2 不同 的 Kubernetes 版 本 对 Docker 的 版 本 要 求 可 能 会 有 不 同 ， 总 
体 上 我 们 建议 使 用 最 新 稳定 的 Docker 版 本 ， 如 果 Kubelet 发 现 Docker 版 
本 过 低 ， 在 创建 Pod 的 时 候 会 失败 并 发 出 告警 日 志 。 








启动 Docker: 


$ docker -d \ 
-H unix:///var/run/docker.sock -H 0.0.0.0:2375 \ 


>> /var/log/docker.log 2>&1 & 
Kubelet 
运行 Kubelet: 


$ kubelet \ 


--logtostderr=true --v=0 \ 


--config=/etc/kubernetes/manifests \ 
--address=0.0.0.0 \ 
--api-servers=http://kube-master:8080 \ 
>> /var/log/kubelet.log 2>&1 & 


Kubernetes Proxy 
运行 Kubelet Proxy: 


$ kube-proxy \ 
--logtostderr=true --v=0 \ 
--api_servers=http://kube-master:8080 \ 


>> /var/log/kube-proxy.log 2>&1 & 


2.2.6 ”查询 Kubernetes 的 健康 状态 


在 部 署 运 行 各 个 组 件 以 后 ， 可 以 通过 Kubernetes 命 令 行 kubectl 查 询 
Kubernetes Master 各 组 件 的 健康 状态 : 


$ kubectl -s http://kube-master:8080 get componentstatus 


NAME STATUS MESSAGE ERROR 
controller-manager Healthy ok nil 
scheduler Healthy ok nil 
etcd-0 Healthy {"health": "true"} nil 


以 及 Kubernetes Node 的 健康 状态 : 


$ kubectl -s http://kube-master:8080 get node 


NAME LABELS STATU 


kube-node-1 kubernetes.io/hostname=kube-node-1 Ready 19m 
kube-node-2 kubernetes.i0/hostname=kube-node-2 Ready 18m 
kube-node-3 kubernetes.io0/hostname=kube-node-3 Ready 18m 


2.2.7 ”创建 Kubernetes 窗 新 网 络 


Kubernetes 的 网 络 模 型 要 求 每 一 个 Pod 都 拥有 一 个 扁平 化 共享 网 络 命 
名 空间 的 卫 ， 称 为 PodIP，Pod 能 够 直接 通过 PodIP 跨 网 络 与 其 他 物理 机 
和 Pod 进 行 通信 。 要 实现 Kubemetes 的 网 络 模型 ， 需 要 在 Kubemetes 集 群 
中 创建 一 个 覆盖 网 络 (Overlay Network) ， 联 通 各 个 节点 ， 目 前 可 以 通 
过 第 三 方 网 络 插件 来 创建 覆盖 网 络 ， 比 如 Flannel 和 Open vSwitch. 


提示 


本 书 中 用 到 的 Kubernetes 运 行 环境 主要 是 使 用 Flannel 实 现 容 器 履 
盖 网 络 的 。 





Flannel 








Flannel] 是 CoreOS 团 队 设 计 开 发 的 一 个 履 盖 网 络 工具 ， 可 以 从 Github 
上 下 载 指定 版 本 的 Flannel 发 布 包 : 


$ wget https://github.com/coreos/flannel/releases/download/v0.5.4 


amd64.tar.gz 


$ tar xzvf flannel-0.5.4-linux-amd64.tar.gz 
$ cd flannel-0.5.4 
$ cp flanneld /usr/bin 


Flannel 使 用 Etcd 进 行 配 置 ， 来 保证 多 个 Flannel 实 例 之 间 的 配置 一 臻 
性 ， 所 以 需要 首先 在 Etcd 上 进行 配置 : 


$ etcdctl -C http://etcd:4001 \ 


set /coreos.com/network/config '{ "Network": "10.0.0.0/16" }' 





在 Kubernetes 的 所 有 节点 上 运行 Flannel: 


$ flanneld -etcd-endpoints=http://etcd:4001 \ 
>> /var/log/flanneld.log 2>&1 & 





Flannel 会 为 不 同 Node 的 Docker 网 桥 配 置 不 同 的 卫 网 段 以 保证 Docker 
容器 的 IP 在 集群 内 唯一 ， 所 以 Flannel 会 重新 配置 Docker 网 桥 ， 需 要 先 删 
除 原 先 创 建 的 Docker 网 桥 : 


$ iptables -t nat -F 
$ ifconfig docker® down 


$ brctl delbr dockerO 


Flannel 运 行 后 会 生成 一 个 文件 subnet.env， 其 中 包含 规划 好 的 
Docker 网 桥 网 段 ， 根 据 其 中 的 属性 重新 启动 Docker: 





$ source /run/flannel/subnet.env 

$ docker -d \ 

-H unix:///var/run/docker.sock -H tcp://0.0.0.0:2375 \ 
--bip=${FLANNEL_SUBNET} --mtu=${FLANNEL_MTU} \ 


>> /var/log/docker.log 2>&1 & 


Open vSwitch 





Open vSwitch 是 一 个 高 质量 的 、 多 层 虚 拟 交 换 机 ， 使 用 开源 Apache 
2.0 许 可 协议 ， 由 Nicira Networks 开 发 。 它 的 目的 是 让 大 规模 网 络 自动 化 
可 以 通过 编程 扩展 ， 同 时 仍然 文 持 标准 的 管理 接口 和 协议 。Open 
vSwitch 是 一 项 非常 重要 的 SDN 技 术 ， 可 以 实现 Kubernetes 中 的 履 盖 网 
络 。 





为 保证 Docker 容 右 的 IP 在 集群 内 唯一 ， 不 同 Kubernetes Node 的 
Docker 网 桥 配 置 成 不 同 的 IP 网 段 ， 需 要 进行 规划 ， 如 表 2-5 所 示 。 





表 2-5 Kubernetes Node 的 Docker 网 桥 规划 





ae 主机 名 IP Docker 网 桥 


Kubernetes kube-node-1 192.168.3.147 | 10.246.0.1/24 
Node 1 
Kubernetes kube-node-2 192.168.3.148 | 10.246.1.1/24 
Node 2 
Kubernetes kube-node-3 192.168.3.149 | 10.246.2.1/24 
Node 3 


安装 运行 Open VSwitch 服 务 以 后 ， 可 以 下 载 一 个 工具 来 协助 创建 
Open vSwitch 网 络 : 


$ wget https://raw.githubusercontent .com/wulonghui/docker -net-too 


$ chmod 0750 k8s-ovs-ctl 


$ mv k8s-ovs-ctl /usr/bin/ 


在 Kubernetes Node 上 配置 ~ /k8s-ovs.env: 
e Kubernetes Node 1 


DOCKER_BRIDGE=docker0O 
CONTAINER_ADDR=10.246.0.1 
CONTAINER_NETMASK=255. 255. 255.0 
CONTAINER_SUBNET=10. 246.0.0/16 


OVS_SWITCH=obr0 
TUNNEL_BASE=gre 


DOCKER_OVS_TUN=tun0 


LOCAL_IP=192.168.3.147 


NODE_IPS=(192.168.3.147 192.168.3.148 192.168.3.149) 


CONTAINER_SUBNETS=(10.246.0.1/24 10.246.1.1/24 


。 Kubernetes Node 2 


DOCKER_BRIDGE=docker0O 
CONTAINER_ADDR=10.246.1.1 
CONTAINER_NETMASK=255. 255. 255.0 
CONTAINER_SUBNET=10.246.0.0/16 


OVS_SWITCH=obr0 
TUNNEL_BASE=gre 


10.246.2.1/24) 


DOCKER_OVS_TUN=tuno 


LOCAL_IP=192.168.3.148 


NODE_IPS=(192.168.3.147 192.168.3.148 192.168.3.149) 


CONTAINER_SUBNETS=(10.246.0.1/24 10.246.1.1/24 


。 Kubernetes Node 3 


DOCKER_BRIDGE=docker0O 
CONTAINER_ADDR=10. 246.2.1 
CONTAINER_NETMASK=255. 255. 255.0 
CONTAINER_SUBNET=10.246.0.0/16 
OVS_SWITCH=obr0 

TUNNEL_BASE=gre 


DOCKER_OVS_TUN=tun0 


LOCAL_IP=192.168.3.149 


10.246.2.1/24) 


NODE_IPS=(192.168.3.147 192.168.3.148 192.168.3.149) 


CONTAINER_SUBNETS=(10.246.0.1/24 10.246.1.1/24 


配置 完成 后 ， 先 删除 原先 创建 的 Docker 网 桥 : 


$ iptables -t nat -F 
$ ifconfig docker® down 


$ brctl delbr dockerO 


然后 使 用 k8s-ovs-ctl 创 建 Open vSwitch | 24 : 


$ k8s-ovs-ctl setup 


10.246.2.1/24) 


最 后 重新 运行 Docker: 


$ docker -d \ 

-H unix:///var/run/docker.sock -H tcp://0.0.0.0:2375 \ 
--bridge=dockerO \ 

>> /var/log/docker.log 2>&1 & 


2.3 ”安装 Kubernetes 扩 展 插 件 


Kubernetes 中 提供 了 许多 平台 扩展 插件 (Cluster Add-on) ， 包 含 在 
Kubernetes 发 布 包 中 ， 可 以 在 Kubernetes 上 进行 安装 部 署 ， 目 前 包含 以 下 
扩展 插件 : 


e Cluster DNS 
e Cluster Monitoring 
e Cluster Logging 


e Kube UI 


提示 


Kubernetes 平 台 扩 展 插 件 并 不 是 必 雷 的， 初次 部 署 可 以 跳 过 此 章 
节 ， 待 后 续 阅 读 中 有 需要 再 进行 安装 。 





2.3.1 安装 Cluster DNS 


Cluster DNS 扩展 插件 用 于 支持 Kubernetes 的 服务 发 现 机 制 ，Cluster 
DNS 主要 包含 如 下 几 项 。 


。SkyDNS: 提供 DNS 解析 服务 。 
。Etcd: 用 于 SkyDNS 的 存储 。 


e Kube2sky: 监听 Kubermetes， 当 有 新 的 Service 创 建 时 ， 生 成 相应 
记录 到 SkyDNS 。 


下 载 Kubernetes 发 布 包 ，Cjluster DNS 扩展 插件 在 Kubernetes 发 布 包 
的 cluster/addons/dns 目 录 下 : 


$ wget https://github.com/kubernetes/kubernetes/releases/download 
$ tar zxvf kubernetes.tar.gz 


$ cd kubernetes/cluster/addons/dns 





通过 环境 变量 配置 参数 : 


$ export DNS_SERVER_IP="10.254.10.2" 
$ export DNS_DOMAIN="cluster.local" 


$ export DNS_REPLICAS=1 


设置 Cluster DNS ServerHJIPy10.254.10.2, Cluster DNS 的 本 地 域 为 
cluster.local， 另 外 需要 配置 到 Kubelet 的 局 动 参数 中 : 


--cluster-dns=10.254.10.2 


--cluster-domain=cluster.local 


Kubernetes 发 布 包 clusteraddons/dns 目 录 下 的 skydns-rc.yaml.in 和 
skydns-svc.yaml.in 是 两 个 模板 文件 ， 通 过 设置 的 环境 变量 修改 其 中 相应 
的 属性 值 ， 生 成 Replication Controller 和 Service 的 定义 文件 : 


$ sed -e "s/{{ pillar\['dns_replicas'\] }}/${DNS_REPLICAS}/g;s/{{ 


domain'\]}}/${DNS_DOMAIN}/g;" \skydns-rc.yaml.in > skydns-rc.yaml 


$ sed -e "S/{{ pillar\['dns_server'\] }}/${DNS_SERVER_IP}/g" skyd 


skydns-svc.yaml 


Cluster DNS Replication Controller 的 定义 文件 skydns-rc.yaml 如 下 : 


apiVersion: v1 
kind: ReplicationController 
metadata: 
name: kube-dns-v9 
namespace: kube-system 
labels: 
k8s-app: kube-dns 


version: v9 


kubernetes.io/cluster-service: 


spec: 
replicas: 1 
selector: 
k8s-app: kube-dns 
version: v9 


template: 


"true" 


metadata: 
labels: 
k8s-app: kube-dns 
version: v9 
kubernetes.io/cluster-service: "true" 
spec: 
containers: 
- name: etcd 
image: gcr.io/google_containers/etcd:2.0.9 
resources: 
limits: 
cpu: 100m 
memory: SOMi 
command: 
- /usr/local/bin/etcd 
- -data-dir 
- /var/etcd/data 
- -listen-client-urls 
- http://127.0.0.1:2379, http://127.0.0.1:4001 
- -advertise-client-urls 
- http://127.0.0.1:2379, http://127.0.0.1:4001 
- -initial-cluster-token 
- skydns-etcd 
volumeMounts: 
- name: etcd-storage 
mountPath: /var/etcd/data 


- name: kube2sky 


image: gcr.io0/google_containers/kube2sky:1.11 
resources: 
limits: 
cpu: 100m 
memory: SOMi 
args: 
# command = "/kube2sky" 
- -domain=cluster.local 
- -kube_master_url=http://kube-master : 8080 
name: skydns 
image: gcr.io/google_containers/skydns:2015-10-13-8c72f8c 
resources: 
limits: 
cpu: 100m 
memory: SOMi 
args: 
# command = "/skydns" 
- -machines=http://127.0.0.1:4001 
- -addr=0.0.0.0:53 
- -ns-rotate=false 
- -domain=cluster.local. 
ports: 
- containerPort: 53 
name: dns 
protocol: UDP 
- containerPort: 53 


name: dns-tcp 


protocol: TCP 
livenessProbe: 
httpGet: 
path: /healthz 
port: 8080 
scheme: HTTP 
initialDelaySeconds: 30 
timeoutSeconds: 5 
readinessProbe: 
httpGet: 
path: /healthz 
port: 8080 
scheme: HTTP 
initialDelaySeconds: 1 
timeoutSeconds: 5 
- name: healthz 
image: gcr.i0/google_containers/exechealthz:1.0 
resources: 
limits: 
cpu: 10m 
memory: 20M1 
args: 
- -cmd=nslookup kubernetes.default.svc.cluster.local loca 
- -port=8080 
ports: 
- containerPort: 8080 


protocol: TCP 


volumes: 
- name: etcd-storage 
emptyDir: {} 


dnsPolicy: Default # Don't use cluster DNS. 


提示 


kube2sky 需 要 Service ”Account 来 调用 Kubernetes API, aR 
Kubernetes 没 有 开局 Service Account， 可 以 显 式 指定 Kubernetes API 的 
URL， 在 skydns-rc.yaml 中 设置 Kube2sky 的 启动 参数 如 下 所 示 。 


args: 
# command = "/kube2sky" 


- -domain=cluster.local 





通过 定义 文件 创建 Cluster DNS Replication Controller: 


$ kubectl create -f skydns-rc.yaml 


replicationcontroller "kube-dns-v9" created 


Cluster DNS Replication Controllerf!| iz 47 Cluster DNS Pod: 


$ kubectl get pod --selector k8s-app=kube-dns --namespace=kube-sy 
NAME READY STATUS RESTARTS AGE 


kube-dns-v9-qdck6 4/4 Running 0 2m 


Cluster DNS Service 的 定义 文件 skydns-svc.yaml: 


apiVersion: v1 
kind: Service 
metadata: 
name: kube-dns 
namespace: kube-system 
labels: 
k8s-app: kube-dns 
kubernetes.io/cluster-service: "true" 
kubernetes.io0/name: "KubeDNS" 
spec: 
selector: 
k8s-app: kube-dns 
ClusterIP: 10.254.10.2 


ports: 
- name: dns 
port: 53 


protocol: UDP 
- name: dns-tcp 
port: 53 


protocol: TCP 


通过 定义 文件 创建 Cluster DNS Service: 


$ kubectl create -f skydns-svc.yaml 


service "kube-dns" created 


然后 可 以 查询 Cluster DNS Service: 


$ kubectl get service -1 k8s-app=kube-dns --namespace=kube-system 
NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELECTO 
kube-dns 10.254.10.2 <none> 53/UDP,53/TCP k8s-app=k 


Cluster DNS 部 署 完 成 后 ， 可 以 创建 Pod 进 行 验证 : 


$ kubectl exec my-pod -- nslookup kubernetes.default.cluster.loca 
server: 10.254.10.2 


Address 1: 10.254.10.2 


Name: kubernetes.default.cluster.local 


Address 1: 10.254.0.1 


2.3.2 ”安装 Cluster Monitoring 


Kubernetes 提 供 J Cluster Monitoring 作 为 平台 监控 支持 ，Cluster 
Monitoring 的 主体 是 Heapster， 一 个 容器 集群 的 监控 收集 工具 ， 将 收集 
Kubernetes 运 行 乎 台 的 监控 数据 ， 文 持 导 入 到 其 他 第 三 方 系统 ， 比 如 
InfluxDB 和 GCE。 





下 载 Kubernetes 发 布 包 ，Cluster Monitoring 扩 展 插 件 在 Kubernetes 发 
布 包 的 cluster/ addons/cluster-monitoring 目 录 下 : 


$ wget https://github.com/kubernetes/kubernetes/releases/download 


$ tar zxvf kubernetes.tar.gz 


$ cd kubernetes/cluster/addons/cluster -monitoring 


在 Kubernetes 发 布 包 的 clustevaddons/cluster-monitoring 目录 中 包含 以 
下 子 目 录 ， 每 个 子 目 录 中 存放 着 不 同 的 定义 文件 。 


e standalone: 部 署 独立 运行 的 Heapster。 

。influxdb: 部 署 Heapster 对 接 InfluxDB。 

。google: 部 署 Heapster 对 接 GCE。 

。googleinfluxdb: 7) Heapster* #GCE All InfluxDB. 


我 们 将 部 署 Heapster 对 接 InfluxDB，InfluxDB 是 一 个 开源 分 布 式 时 
序 、 事 件 和 指标 数据 库 ， 同 时 ，InfluxDB 集 成 Grafana 提 供 图 表 展 示 功 


AB 
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部 署 InfluxDB 和 Grafana 


Influxdb&Grafana Replication Controller 的 定义 文件 influxdb/influxdb- 


grafana-controller. yaml: 


apiVersion: v1 
kind: ReplicationController 
metadata: 
name: monitoring-influxdb-grafana-v2 
namespace: kube-system 
labels: 
k8s-app: influxGrafana 


version: v2 


kubernetes.io/cluster-service: "true" 
spec: 
replicas: 1 
selector: 
k8s-app: influxGrafana 
version: v2 
template: 
metadata: 
labels: 
k8s-app: influxGrafana 
version: v2 
kubernetes.io/cluster-service: "true" 
spec: 
containers: 
- image: gcr.io0/google_containers/heapster_influxdb:v0.4 
name: influxdb 
resources: 
limits: 
cpu: 100m 
memory: 200Mi 
ports: 
- containerPort: 8083 
hostPort: 8083 
- containerPort: 8086 
hostPort: 8086 
volumeMounts: 


- name: influxdb-persistent-storage 


mountPath: /data 


- image: beta.gcr.io/google_containers/heapster_grafana:v 


name: grafana 


env: 


resources: 


limits: 


env: 


cpu: 


100m 


memory: 100Mi 


This variable is required to setup templates in Gra 


name: INFLUXDB_SERVICE_URL 


value: http://monitoring-influxdb: 8086 


# The following env variables are required to make 


# the kubernetes api-server proxy. On production cl 


# removing these env variables,setup auth for grafa 


# service using a LoadBalancer or a public IP. 


#- name: GF_AUTH_BASIC_ENABLED 

# value: "false" 

#- name: GF_AUTH_ANONYMOUS_ENABLED 

# value: "true" 

#- name: GF_AUTH_ANONYMOUS_ORG_ROLE 

# value: Admin 

#- name: GF_SERVER_ROOT_URL 

# alue: /api/vi/proxy/namespaces/kube-system/servi 
volumeMounts: 


- name: grafana-persistent-storage 


mountPath: /var 


volumes: 

- name: influxdb-persistent-storage 
emptyDir: {} 

- name: grafana-persistent-storage 


emptyDir: {} 


提示 


influxdb/influxdb-grafana-controller.yaml 中 注释 掉 Grafana 容 器 的 环 
境 变 量 : 


# The following env variables are required to make Grafana acces 
# the kubernetes api-server proxy. On production clusters, we re 
# removing these env variables,setup auth for grafana,and expose 
# service using a LoadBalancer or a public IP. 

name: GF_AUTH_BASIC_ENABLED 

value: "false" 

name: GF_AUTH_ANONYMOUS_ENABLED 

value: "true" 

name: GF_AUTH_ANONYMOUS_ORG_ROLE 

value: Admin 

name: GF_SERVER_ROOT_URL 


alue: /api/vi/proxy/namespaces/kube-system/services/monitori 





通过 定义 文件 创建 Influxdb&Grafana Replication Controller: 


$ kubectl create -f influxdb/influxdb-grafana-controller.yaml 


replicationcontroller "monitoring-influxdb-grafana-v2" created 


Influxdb&Grafana Replication Controller!) iz 47 Influxdb&Grafana 
Pod: 


$ kubectl get pod --selector k8s-app=influxGrafana --namespace=ku 
NAME READY STATUS 


monitoring-influxdb-grafana-v2-v5e4y 2/2 Running 0 





在 Pod 的 查询 信息 中 ， 属 性 NODE 显 示 Pod 运 行 在 Node kube-node-2 
上 上 ， 因 为 Pod 中 为 Influxdb 容 器 设置 了 端口 映射 规则 (8083:8083) ， 于 
是 便 可 以 通过 Node kube-node-2 访 问 到 Influxdb 的 Web 界 面 ， 访 问 地 址 是 
http://kube-node-2:8083， 如 图 2-2 所 示 。 




















图 2-2 访问 Influxdb Web 界 面 


Influxdb Service 的 定义 文件 influxdb/influxdb-service.yaml: 


apiVersion: v1 


kind: Service 


metadata: 
name: monitoring-influxdb 
namespace: kube-system 
labels: 
kubernetes.io/cluster-service: "true" 


kubernetes.io/name: "InfluxDB" 


spec: 
ports: 
- name: http 
port: 8083 
targetPort: 8083 
- name: api 
port: 8086 
targetPort: 8086 
selector: 


k8s-app: influxGrafana 


通过 定义 文件 创建 Influxdb Service: 


$ kubectl create -f influxdb/influxdb-service.yaml 


service "monitoring-influxdb" created 


Grafana Service 的 定义 文件 influxdb/grafana-service.yaml: 


apiVersion: v1 
kind: Service 
metadata: 


name: monitoring-grafana 


namespace: kube-system 
labels: 
kubernetes.io/cluster-service: "true" 
kubernetes.io/name: "Grafana" 
spec: 
type: NodePort 
ports: 
- port: 80 
targetPort: 3000 
selector: 


k8s-app: influxGrafana 


其 中 设置 Grafana Service 的 类 型 为 NodePort， 这 样 一 来 ，Kubernetes 
会 为 Service 创 建 一 个 端口 NodePort， 通 过 [Kubernetes Node IP]: 
[NodePort] 束 可 以 访问 到 Service。 


通过 定义 文件 创建 Grafana Service: 


$ kubectl create -f influxdb/grafana-service.yaml 
You have exposed your service on an external port on all nodes in 
cluster. If you want to expose this service to the external inte 


need to set up firewall rules for the service port(s) (tcp:32075) 


See http://releases.k8s.i0/release-1.1/docs/user -guide/services-f 


service "monitoring-grafana" created 


从 Grafana Service 创 建成 功 的 提示 中 可 以 知道 Kubernetes 分 配 的 
NodePort 是 tcp:32075， 那 么 通过 http://kube-node-2:32075 可 以 访问 


Grafana， 如 图 2-3 所 示 。 


(Giroirelate 





图 2-3 访问 Grafana 
部 署 Heapster 


Heapster Replication Controller 的 定义 文件 influxdb/heapster- 


controller.yaml: 


apiVersion: v1 
kind: ReplicationController 
metadata: 
name: heapster-v10 
namespace: kube-system 
labels: 
k8s-app: heapster 
version: v10 
kubernetes.io/cluster-service: "true" 
spec: 


replicas: 1 


selector: 
k8s-app: heapster 
version: v10 
template: 
metadata: 
labels: 
k8s-app: heapster 
version: v10 
kubernetes.io/cluster-service: "true" 
spec: 
containers: 
- image: gcr.io/google_containers/heapster:v0.18.2 
name: heapster 
resources: 
limits: 
cpu: 100m 
memory: 300Mi 
command: 
- /heapster 
- --source=kubernetes:http://kube-master :8080?inClust 
false&useServiceAccount=false 
- --Sink=influxdb:http://monitoring-influxdb: 8086 
- --stats_resolution=30s 


- --Sink_frequency=1m 


提示 


Heapster 需 要 Service Account% ił] H Kubernetes API, WR 
Kubernetes 没 有 开局 Service Account， 可 以 显 式 指 定 Kubernetes API 的 
URL， 可 在 skydns-rc.yaml 中 设置 Heapster 的 启动 参数 。 





command: 

- /heapster 

- --Source=kubernetes:http://kube-master:8080?inClusterConfig=f 
false 

- --Sink=influxdb:http://monitoring-influxdb:8086 

- --Stats_resolution=30s 


- --Sink_frequency=1m 


通过 定义 文件 创建 Heapster Replication Controller: 


$ kubectl create -f influxdb/heapster-controller.yaml 


replicationcontroller "heapster-v10" created 


Heapster Replication Controller 创 建 运行 Heapster Pod: 


$ kubectl get pod --selector k8s-app=heapster --namespace=kube-sy 
NAME READY STATUS RESTARTS AGE 


heapster-v10-s8jc1 1/1 Running 0 44s 


Heapster 运 行 后 会 收集 Kubernetes 的 监控 数据 ， 导 入 到 InfluxDB， 然 
后 就 可 以 通过 Grafana 碍 看 数据 图 表 展 示 ， 如 网 2-4 所 示 。 





图 2-4 Grafana 展 示 Kubernetes 监 控 


Heapster Service 的 定义 文件 influxdb/heapster-service.yaml: 


kind: Service 
apiVersion: v1 
metadata: 
name: heapster 
namespace: kube-system 
labels: 
kubernetes.io/cluster-service: "true" 


kubernetes.io/name: "Heapster" 


spec: 
ports: 
- port: 80 
targetPort: 8082 
selector: 


k8s-app: heapster 


通过 定义 文件 创建 Heapster Service: 


$ kubectl create -f influxdb/heapster-service.yaml 


service "heapster" created 


Heapster Service 创 建成 功 后 就 可 以 通过 Kubernetes API Server 提 供 的 
Proxy 接 口 调用 Heapster 的 Rest API: 


$ curl http://kube-master :8080/api/vi/proxy/namespaces/kube-syste 


2.3.3 24&Cluster Logging 


Kubernetes 提 供 了 Cluster Logging 作 为 平台 日 志 ，Cluster Logging (i 
用 Fluentd+Elasticsearch+ Kibana 来 收集 、 汇 总 和 展示 Kubernetes 运 行 平台 
的 日 志 。 


下 载 Kubernetes 发 布 包 ，Cluster Logging 扩 展 插件 在 发 布 包 的 
Kubernetes/cluster/addons/ fluentd-elasticsearch 上 月 孙 下 : 


$ wget https://github.com/kubernetes/kubernetes/releases/download 
$ tar zxvf kubernetes.tar.gz 


$ cd kubernetes/cluster/addons/fluentd-elasticsearch 
74}  Elasticsearch 


Elasticsearch Replication Controller 的 定义 文件 es-controller.yaml: 


apiVersion: v1 
kind: ReplicationController 


metadata: 


name: elasticsearch-logging-v1 
namespace: kube-system 
labels: 
k8s-app: elasticsearch-logging 
version: v1 
kubernetes.io/cluster-service: "true" 
spec: 
replicas: 2 
selector: 
k8s-app: elasticsearch-logging 
version: v1 
template: 
metadata: 
labels: 
k8s-app: elasticsearch-logging 
version: v1 
kubernetes.io/cluster-service: "true" 
spec: 

containers: 

- image: gcr.io0/google_containers/elasticsearch:1.7 
name: elasticsearch-logging 
resources: 

limits: 
cpu: 100m 
ports: 
- containerPort: 9200 


name: db 


protocol: TCP 
- containerPort: 9300 
name: transport 
protocol: TCP 
volumeMounts: 
- name: es-persistent-storage 
mountPath: /data 
volumes: 
- name: es-persistent-storage 


emptyDir: {} 


通过 定义 文件 创建 Elasticsearch Replication Controller: 


$ kubectl create -f es-controller.yaml 


replicationcontroller "elasticsearch-logging-vi" created 


Elasticsearch Replication Controller # iz 4J Elasticsearch Pod: 


$ kubectl get pod --selector k8s-app=elasticsearch-logging --name 


NAME READY STATUS RESTA 
elasticsearch-logging-v1-joxgq 1/1 Running 0 
elasticsearch-logging-v1i-ofmn2 1/1 Running 0 


Elasticsearch Service 的 定义 文件 es-service.yaml: 


apiVersion: v1 
kind: Service 
metadata: 


name: elasticsearch-logging 


namespace: kube-system 

labels: 
k8s-app: elasticsearch-logging 
kubernetes.io/cluster-service: "true" 
kubernetes.io/name: "Elasticsearch" 

spec: 

ports: 

- port: 9200 
protocol: TCP 
targetPort: db 

selector: 


k8s-app: elasticsearch-logging 


通过 定义 文件 创建 Elasticsearch Service: 


$ kubectl create -f es-service.yaml 


service "elasticsearch-logging" created 


Elasticsearch Service 创 建成 功 后 ， 可 以 通过 Kubernetes API Server 提 
供 的 Proxy 接 口 访问 Elasticsearch， 如 图 2-5 所 示 。 














部 署 Kibana 


图 2-5 访问 Elasticsearch API 


Kibana Replication Controller 的 定义 文件 kibana-controller.yaml: 


apiVersion: vi 


kind: ReplicationController 


metadata: 
name: kibana-logging-v1i 
namespace: kube-system 
labels: 
k8s-app: kibana-logging 
version: v1 
kubernetes.io/cluster-service: "true" 
spec: 


replicas: 1 
selector: 


k8s-app: 


kibana- logging 


version: v1 
template: 
metadata: 
labels: 
k8s-app: kibana-logging 
version: v1 
kubernetes.io/cluster-service: "true" 
spec: 
containers: 
- name: kibana-logging 
image: gcr.io/google_containers/kibana:1.3 
resources: 
limits: 
cpu: 100m 
env: 
- name: "ELASTICSEARCH_URL" 
value: "http://elasticsearch-logging:9200" 
ports: 
- containerPort: 5601 
name: ui 


protocol: TCP 


通过 定义 文件 创建 Kibana Replication Controller: 


$ kubectl create -f kibana-controller.yaml 


replicationcontroller "kibana-logging-vi" created 


Kibana Replication Controller 创 建 运行 Kibana Pod: 


$ kubectl get pod --selector k8s-app=kibana-logging --namespace=k 
NAME READY STATUS RESTARTS AGE 


kibana-logging-v1i-xqjhz 1/1 Running 1 2m 


Kibana Service 的 定义 文件 kibana-service.yaml: 


apiVersion: v1 
kind: Service 
metadata: 
name: kibana-logging 
namespace: kube-system 
labels: 
k8s-app: kibana-logging 
kubernetes.io/cluster-service: "true" 
kubernetes.io/name: "Kibana" 
spec: 
ports: 
- port: 5601 
protocol: TCP 
targetPort: ui 
selector: 


k8s-app: kibana-logging 


通过 定义 文件 创建 Kibana Service: 


$ kubectl create -f kibana-service.yaml 


service "kibana-logging" created 


Kibana Service 创 建成 功 后 ， 就 可 以 通过 Kubernetes API Server 提 供 
的 Proxy 接 口 访问 Kibana， 如 图 2-6 所 示 。 
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图 2-6 访问 Kibana 


部 署 Fluentd 





Fluentd 作 为 Logging Agent 需 要 运行 在 所 有 Kubernetes 节 点 上 ， 我 们 
通过 Kubelet 将 其 作为 Static Pod (参考 12.1.1 节 ) 运行 。 


在 所 有 Kubernetes Node 上 ， 在 Kubelet 的 目 
录 /etc/kubernetes/manifests 下 放 入 Fluentd Pod 的 定义 文件 fluentd- 
es.yaml: 


apiVersion: v1 

kind: Pod 

metadata: 
name: fluentd-elasticsearch 
namespace: kube-system 


spec: 


containers: 

- name: fluentd-elasticsearch 
image: gcr.io/google_containers/fluentd-elasticsearch:1.11 
resources: 

limits: 
cpu: 100m 
args: 
- -q 
volumeMounts: 
- name: varlog 
mountPath: /var/log 
- name: varlibdockercontainers 
mountPath: /var/lib/docker/containers 
readOnly: true 

terminationGracePeriodSeconds: 30 

volumes: 

- name: varlog 
hostPath: 

path: /var/log 

- name: varlibdockercontainers 

hostPath: 


path: /var/lib/docker/containers 


然后 Kubelet 就 会 在 所 有 Kubernetes Node 上 运行 Fluentd Pod: 


$ kubectl get pod --selector k8s-app=fluentd-logging --namespace= 
NAME READY STATUS RE 


fluentd-elasticsearch-kube-node-1 1/1 Running 0 
fluentd-elasticsearch-kube-node-2 1/1 Running 0 


fluentd-elasticsearch-kube-node-3 1/1 Running 0 


Fluentd 运 行 后 ， 将 会 收集 日 志 并 导入 到 Elasticsearch， 从 而 可 以 通 
过 Kibana 查 询 到 | Ele ICD 9 如 图 2-7 所 示 o 
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图 2-7 kenge a 日 志 


2.3.4 Kube UI 


Kube UI 是 Kubermetes 提 供 的 Web 管 理 界面 ， 下 载 Kubernetes 发 布 
包 ，Kube UI 扩展 插件 在 Kubernetes 发 布 包 的 cluster/addons/kube-ui 目 录 
下 : 


$ wget https://github.com/kubernetes/kubernetes/releases/download 
$ tar zxvf kubernetes.tar.gz 


$ cd kubernetes/cluster/addons/kube -ui 


Kube UI Replication Controller 的 定义 文件 kube-ui-rc.yaml: 


apiVersion: v1 
kind: ReplicationController 
metadata: 
name: kube-ui-v2 
namespace: kube-system 
labels: 
k8s-app: kube-ui 
version: v2 
kubernetes.io/cluster-service: "true" 
spec: 
replicas: 1 
selector: 
k8s-app: kube-ui 
version: v2 
template: 
metadata: 
labels: 
k8s-app: kube-ui 
version: v2 
kubernetes.io/cluster-service: "true" 
spec: 
containers: 
- name: kube-ui 
image: gcr.io/google_containers/kube-ui:v2 


resources: 


limits: 
cpu: 100m 
memory: SOMi 
ports: 
- containerPort: 8080 
livenessProbe: 
httpGet: 
path: / 
port: 8080 
initialDelaySeconds: 30 


timeoutSeconds: 5 


通过 定义 文件 创建 Kube UI Replication Controller: 


$ kubectl create -f kube-ui-rc.yaml 


replicationcontroller "kube-ui-v2" created 


Kube UI Replication Controller!) #£iZ {7 Kube UI Pod: 


$ kubectl get pods -1 k8s-app=kube-ui --namespace=kube-system 
NAME READY STATUS RESTARTS AGE 


kube-ui-v2-6g00g 1/1 Running 0 28s 


Kube UI Service 的 定义 文件 kube-ui-svc.yaml: 


apiVersion: v1 
kind: Service 
metadata: 


name: kube-ui 


namespace: kube-system 
labels: 
k8s-app: kube-ui 


kubernetes.io/cluster-service: 


kubernetes.i0/name: "KubeUI" 
spec: 
selector: 
k8s-app: kube-ui 
ports: 
- port: 80 
targetPort: 8080 


"true" 


通过 定义 文件 创建 Kube UI Service: 


$ kubectl create -f kube-ui-rc.yaml 


replicationcontroller "kube-ui-v2" created 


Kube UI Service 创 建成 功 后 就 可 以 通过 Kubernetes API Server 的 接口 


访问 到 Kube UI， 如 图 2-8 所 示 。 

















图 2-8 访问 Kube UI 


第 3 章 
Kubernetes 快 速 入 门 


Kubernetes 是 容器 集群 管理 系统 ， 为 容器 化 的 应 用 提供 资源 调度 、 
部 蜀 运 行 、 容 灾 容 错 和 服务 发 现 等 功能 。 本 章 通 过 一 个 完整 示例 演示 
Kubernetes 的 基本 功能 ， 其 中 涉及 Pod、Replication Controller 和 Service 这 
三 个 Kubernetes 基 本 要 素 的 功能 展示 ， 从 而 帮助 读者 快速 理解 


Kubernetes 。 





3.1 示例 应 用 Guestbook 





本 章 要 演示 的 示例 应 用 是 一 个 名 叫 Guestbook 的 应 用 ，Guestbook 是 
一 个 典型 的 Web 应 用 。Guestbook 的 部 署 运 行 结构 如 图 3-1 所 示 。 





Redis Slave Redis Slave 


Guestbook 包 含 两 部 分 。 





Replicate 


图 3-1Guestbook 结 构 


¢ Frontend 


Guestbook 的 Web 前 端 部 分 ， 无 状态 节点 ， 可 以 方便 伸缩 ， 本 例 中 
将 运行 3 个 实例 。 
e Redis 


Guestbook 的 存储 部 分 ，Redis 采 用 主 备 模式 ， 即 运行 1 个 Redis 
Master 和 2 个 Redis Slave, Redis Slave 会 从 Redis Master 同 步 数据 。 


Guestbook 提 供 一 个 非常 简单 的 功能 : 在 Frontend 页 面 提交 数据 ， 
Frontend 则 将 数据 保存 到 Redis Master， 然 后 从 Redis Slave 读 取 数 据 显示 
到 页 面 上 。 


Guestbook 定 义 文件 在 Kubernetes 发 布 包 的 examples/guestbook 目 录 
下 : 


$ wget https://github.com/kubernetes/kubernetes/releases/download 
$ tar zxvf kubernetes.tar.gz 


$ cd kubernetes/examples/guestbook 


3.2 ”准备 工作 


需要 准备 一 套 Kubernetes 运 行 环境 ， 可 参考 2.2 节 的 介绍 。 另 外 ， 
Kubernetes 需 要 安装 Cluster DNS， 可 参考 2.3.1 节 的 介绍 。 











本 文 使 用 的 Kubernetes 环 境 信 息 如 下 所 示 。 


$ kubectl cluster-info 
Kubernetes master is running at http://k8s-master : 8080 
KubeDNS is running at http://k8s-master :8080/api/v1/proxy/namespa 


services/kube-dns 


$ kubectl -s http://kube-master:8080 get componentstatuses 


NAME STATUS MESSAGE ERROR 
controller-manager Healthy ok nil 
scheduler Healthy ok nil 
etcd-0 Healthy {"health": "true"} nil 


$ kubectl -s http://kube-master:8080 get nodes 


NAME LABELS STATU 


kube-node-1 kubernetes.io/hostname=kube-node-1 Ready 19m 
kube-node-2 kubernetes.i0/hostname=kube-node-2 Ready 18m 
kube-node-3 kubernetes.io0/hostname=kube-node-3 Ready 18m 


3.3 ”运行 Redis 


首先 在 Kubernetes 上 部 亚运 行 Redis， 包 括 Redis Master 和 Redis 


Slave. 


3.3.1 创建 Redis Master Pod 


Pod 是 Kubernetes 的 基本 处 理 单元 ，Pod 包 含 一 个 或 者 多 个 相关 的 容 
器 ， 应 用 将 以 Pod 的 形式 运行 在 Kubernetes 中 〈 本 质 上 是 运行 容器 ) 。 而 
Replication Controller 能 够 控制 Pod 按 照 指定 副本 数目 持续 运行 ， 一 般 情 
况 下 是 通过 Replication Controller 来 创建 Pod， 来 保证 Pod 的 可 靠 性 。 


Redis Master Replication Controller 的 定义 文件 redis-master- 


controller.yaml: 


apiVersion: v1 
kind: ReplicationController 
metadata: 
name: redis-master 
labels: 


name: redis-master 


spec: 
replicas: 1 
selector: 
name: redis-master 
template: 
metadata: 
labels: 
name: redis-master 
spec: 
containers: 
- name: master 
image: redis 
ports: 


- containerPort: 6379 


在 Kubernetes 中 ， 主 要 通过 文件 来 定义 API 对 象 ， 定 义 文件 形式 更 加 
清晰 ， 也 方便 保存 和 修改 ， 定 义 文 件 格 式 支 持 JSON 和 YAML， 本 书 主 
要 使 用 YAML 格 式 。 





定义 文件 中 首先 声明 了 API 对 象 的 基本 属性 : API 版 本 

(.apiVersion) 、API 对 象 类 型 〈.kind) 和 元 数据 (metadata) , EXX 
件 redis-master-controller.yaml 中 定义 了 V1 版 本 下 一 个 名 称 为 redis-master 
的 Replication Controller。 另 外 配置 了 Replication ”Controller 的 规格 

(spec) ， 其 中 设置 了 Pod 的 副本 数 〈.spec.replicas) 和 Pod 模 板 

(.spec.template〉。Pod 模 板 中 说 明了 Pod 包 含 一 个 容器 ， 该 容器 使 用 镜 
像 redis， 即 运行 Redis Master， 该 Replication Controller 将 关联 1 个 这 样 的 
Pod， 而 Replication Controller 和 Pod 的 关联 是 通过 Label 来 实现 


(.spec.selector 和 .spec.template.metadata.labels) 的 。 


通过 定义 文件 创建 Redis Master Replication Controller: 


$ kubectl create -f redis-master-controller.yaml 


replicationcontroller "redis-master" created 


创建 成 功 后 ， 可 查询 Redis Master Replication Controller: 


$ kubectl get replicationcontroller redis-master 
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPL 


redis-master master redis name=redis-master 1 


Redis Master Replication Controller 将 会 创建 1 个 Redis Master Pod, i! 
建 出 来 的 Pod 就 会 带 上 Label name=redis-master: 


$ kubectl get pod --selector name=redis-master 
NAME READY STATUS RESTARTS AGE 


redis-master-vdkfp 1/1 Running 0 31S 


Replication Controller 在 创建 出 Pod 以 后 ， 将 会 保证 Pod 按 照 指 定 副本 
数目 持续 运行 ， 而 通过 Replication ”Controller 也 可 以 对 Pod 进 行 一 系列 操 
作 ， 包 括 滚动 升级 和 弹性 伸缩 等 。 


3.3.2 ”创建 Redis Master Service 


Kubernetes 中 Pod 是 变化 的 ， 特 别 是 当 受 到 Replication Controller 控 制 
的 时 候 ， 而 当 Pod 发 生变 化 的 时 候 ，Pod 的 卫 也 是 变化 的 。 这 束 导 致 了 一 


个 问题 : 在 Kubernetes 集 群 中 ，Pod 之 间 如 何 互 相 发 现 并 访问 昵 ?比如 我 
们 已 经 运行 了 Redis Master Pod， 那 么 Redis Slave Pod 如 何 获 取 Redis 
Master “Pod 的 访问 地 址 呢 ? 为 此 Kubernetes 提 供 了 Service 来 实现 服务 发 
现 。 


Kubernetes 中 Service 是 真实 应 用 的 抽象 ， 将 用 来 代理 Pod， 对 外 提供 
定 卫 作为 访问 入 口 ， 这 样 通 过 访问 Service 便 能 访问 到 相应 的 Pod， 而 
对 访问 者 来 说 只 需 知 道 Service 的 访问 地 址 ， 而 不 需要 感知 Pod 的 变化 。 





上 一 步 中 已 经 运行 起 Redis Master Pod， 现 在 创建 Redis Master 
Service 来 代理 Redis Master Pod, Redis Master Service 的 定义 文件 redis- 


master-service.yaml: 


apiVersion: v1 
kind: Service 
metadata: 
name: redis-master 
labels: 
name: redis-master 
spec: 
ports: 
# the port that this service should serve on 
- port: 6379 
targetPort: 6379 
selector: 


name: redis-master 


Service 是 通过 Label 来 关联 Pod 的 ， 在 Service 的 定义 中 ， 设 


置 .spec.selector 为 name= redis-master， 将 关联 上 Redis Master Pod. 
通过 定义 文件 创建 Redis Master Service: 


$ kubectl create -f redis-master-service.yaml 


service "redis-master" created 


创建 成 功 后 查看 Redis Master Service: 


$ kubectl get service redis-master 
NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELECT 


redis-master 10.254.233,.212 <none> 6379/TCP name=red 


Redis Master Service 的 查询 信息 中 显示 属性 CLUSTER_IP 为 
10.254.233.212， 属 性 PORT(S) 为 6379/TCP， 其 中 10.254.233.212 是 
Kubernetes 分 配给 Redis Master Service 的 虚拟 IP，6379/TCP 则 是 Service 会 
转发 的 端口 〈 通 过 Service 定 义 文件 中 的 .spec.ports[0].port 指 定 ) ， 
Kubernetes 会 将 所 有 访问 10.254.233.212:6379 的 TCP 请 求 转 发 到 Redis 
Master Pod 中 ， 目 标 端口 是 6379/TCP (通过 Service 定 义 文件 中 的 
spec.ports[0].targetPort 指 定 ) 。 


为 创建 了 Redis Master Service 来 代理 Redis Master Pod， 所 以 Redis 
Slave Pod 通 过 Redis Master Service 的 虚拟 IP 10.254.233.212 了 就 可 以 访问 到 
Redis Master Pod， 但 是 如 果 只 是 便 配 置 Service 的 虚拟 IP 到 Redis Slave 
Pod 中 ， 这 样 还 不 是 真正 的 服务 发 现 ，Kubemetes 提 供 了 两 种 发 现 Service 
ET 


+ 环境 变量 


当 Pod 运 行 的 时 候 ，Kubernetes 会 将 之 前 存在 的 Service 的 信息 通过 环 
培 变量 写 到 Pod 中 ， 以 Redis Master Service 为 例 ， 它 的 信息 会 被 写 到 Pod 
中 


REDIS_MASTER_SERVICE_HOST=10.254.233.212 
REDIS_MASTER_PORT_ 6379_TCP_PROTO=tcp 





REDIS_MASTER_SERVICE_PORT=6379 
REDIS_MASTER_PORT=tcp://10.254.233.212:6379 
REDIS_MASTER_PORT_6379_TCP=tcp://10.254.233.212:6379 





REDIS_MASTER_PORT_6379_TCP_PORT=6379 





REDIS_MASTER_PORT_6379_TCP_ADDR=10. 254.233.212 





这 种 方法 要 求 Pod 必 须 在 Service 之 后 启动 ， 之 前 启动 的 Pod 没 有 这 些 
境 变 量 。 末 用 DNS 方 式 束 没有 这 个 限制 。 


e DNS 


当 有 新 的 Service 创 建 时 ， 就 会 自动 生成 一 条 DNS 记录 ， 以 Redis 
Master Service 为 例 ， 有 一 条 DNS 记录 : 


redis-master => 10.254.233.212 


使 用 这 种 方法 ，Kubernetes 需 要 安装 Cluster DNS， 可 参考 2.3.1 节 的 


介绍 。 


3.3.3 ”创建 Redis Slave Pod 


通过 Replication Controller 可 创建 Redis Slave Pod， 将 创建 两 个 Redis 
Slave Pod. Redis Slave Replication Controller 的 定义 文件 redis-slave- 


controller.yaml: 


kind: ReplicationController 
metadata: 
name: redis-slave 
labels: 
name: redis-slave 
spec: 
replicas: 2 
selector: 
name: redis-slave 
template: 
metadata: 
labels: 
name: redis-slave 
spec: 
containers: 
- name: worker 
image: gcr.io/google_samples/gb-redisslave:v1 
env: 
- name: GET_HOSTS_FROM 
value: dns 
# If your cluster config does not include a dns service 
# instead access an environment variable to find the ma 


# service's host, comment out the 'value: dns' line abc 


# uncomment the line below. 
# value: env 
ports: 


- containerPort: 6379 


Redis Slave Replication Controller 定 义 中 设置 Pod 副 本 数 为 2， 而 Pod 
模板 中 包含 一 个 容器 ， 容 器 使 用 镜像 gcr.io/google_samples/gb- 
redisslave:v1， 该 镜像 实际 上 是 基于 镜像 redis 重 写 了 局 动 脚 本 ， 将 作为 
Redis Master 的 备 节点 启动 ， 启 动 脚本 如 下 : 





if [[ ${GET_HOSTS_FROM: -dns} == "env" ]]; then 
redis-server --slaveof ${REDIS_MASTER_SERVICE_HOST} 6379 
else 
redis-server --slaveof redis-master 6379 


fi 


其 中 通过 环境 变量 GET HOSTS FROM 来 控制 使 用 环境 变量 或 者 
DNS 方式 来 发 现 Redis Master Server。 


提示 


镜像 gcr.io/google_samples/gb-redisslave:v1 的 Dockerfile 参 考 : 


https://github.com/kubernetes/kubernetes/tree/vi.1.1/examples/g 





通过 定义 文件 创建 Redis Slave Replication Controller: 


$ kubectl create -f redis-slave-controller.yaml 


replicationcontroller "redis-slave" created 


创建 成 功 后 ， 查 询 Redis Slave Replication Controller: 


$ kubectl get replicationcontroller redis-slave 
CONTROLLER CONTAINER(S) IMAGE(S) 


redis-slave worker gcr.10/google_samples/gb-redisslave 


Redis Slave Replication Controller 创 建 运行 两 个 Redis Slave Pod: 


$ kubectl get pod --selector name=redis-slave 


NAME READY STATUS RESTARTS AGE 
redis-slave-7g617 1/1 Running 0 24S 
redis-slave-8dhc2 1/1 Running 0 24S 


3.3.4 创建 Redis Slave Service 


创建 Redis Salve Service 来 代理 Redis Salve Pod，Redis Salve Service 
的 定义 文件 redis- slave-service.yaml: 


apiVersion: v1 
kind: Service 
metadata: 
name: redis-slave 
labels: 


name: redis-slave 


spec: 
ports: 
# the port that this service should serve on 
- port: 6379 
selector: 


name: redis-slave 


通过 定义 文件 创建 Redis Salve Service: 


$ kubectl create -f redis-slave-service.yaml 


service "“redis-slave" created 


查询 Redis Salve Service: 


$ kubectl get service redis-slave 
NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELEC 


redis-slave 110.254.108.203 <none> 6379/TCP name=re 


3.4 运行 Erontend 


3.4.1 创建 Erontend Pod 


通过 Frontend Replication Controller 来 创建 Frontend Pod， 将 创建 3 个 
Frontend Pod. 


Frontend Replication Controller 的 定义 文件 frontend-controller.yaml: 


apiVersion: v1 
kind: ReplicationController 
metadata: 
name: frontend 
labels: 
name: frontend 
spec: 
replicas: 3 
selector: 
name: frontend 
template: 
metadata: 
labels: 
name: frontend 
spec: 
containers: 
- name: php-redis 
image: gcr.io0/google_samples/gb- frontend: v3 
env: 
- name: GET_HOSTS_FROM 
value: dns 
If your cluster config does not include a dns service 
instead access environment variables to find service 


info, comment out the 'value: dns' line above, and u 


+ + +H + 


line below. 
# value: env 


ports: 


- containerPort: 80 


Frontend Replication Controller 的 定义 中 设置 Pod 副 本 数 为 3，Pod 模 
板 包 含 一 个 容器 ， 容 器 使 用 镜像 gcr.io/google_samples/gb-frontend:v3， 
这 是 一 个 PHP 实 现 的 Web 应 用 ， 简 单 地 说 将 写 数据 到 Redis Master, JM 
Redis Slave 中 读 取 数据 : 


<? 


set_include_path('.:/usr/local/lib/php' ); 


error_reporting(E_ALL); 


ini_set('display_errors', 1); 


require 'Predis/Autoloader.php'; 


Predis\Autoloader::register(); 


if (isset($_GET['cmd']) === true) { 
$host = 'redis-master'; 
if (getenv('GET_HOSTS_FROM') == 'env') { 


$host = getenv( 'REDIS_ MASTER_SERVICE_HOST'); 
} 
header('Content-Type: application/json'); 
if ($_GET['cmd'] == 'set') { 

$client = new Predis\Client([ 


'scheme' => 'tcp', 


"host ' => $host, 
‘port' => 6379, 
]); 


$client->set($ GET['key'], $_GET['value']); 


print('{"message": "Updated"}'); 


} else { 
$host = 'redis-slave'; 
if (getenv('GET_HOSTS_FROM') == 'env') { 


$host = getenv( 'REDIS_ SLAVE_SERVICE_HOST' ); 
} 
$client = new Predis\Client([ 

'scheme' => 'tcp', 

‘host ' => $host, 

‘port! => 6379, 
]); 


$value = $client->get($_GET['key']); 
print('{"data": "' . $value . '"}'); 
} 
} else { 
phpinfo(); 


} ?> 


代码 中 是 通过 环境 变量 GET_HOSTS_ FROM 来 控制 使 用 环境 变量 
方式 还 是 DNS 方式 来 发 现 Redis Master Server 和 Redis Slave Server 的 。 


提示 


镜像 gcr.io/google_samples/gb-frontend:v3 的 Dockerfile 参 考 : 


https://github.com/kubernetes/kubernetes/tree/vi.1.1/examples/g 





通过 定义 文件 创建 Frontend Replication Controller: 


$ kubectl create -f frontend-controller.yaml 


replicationcontroller "frontend" created 


创建 成 功 后 ， 查 询 Frontend Replication Controller: 


$ kubectl get replicationcontroller frontend 
CONTROLLER CONTAINER(S) IMAGE(S) 


frontend php-redis gcr.10/google_samples/gb-frontend: v3 


Frontend Replication Controller 创 建 运行 3 个 Frontend Pod: 


$ kubectl get pod --selector name=frontend 


NAME READY STATUS RESTARTS AGE 
frontend-1670s 1/1 Running 0 22S 
frontend-2t6sw 1/1 Running 0 21s 
frontend-ehbxc 1/1 Running 0 21s 


3.4.2 ”创建 Erontend Service 


创建 Frontend Service 代 理 Frontend Pod, Frontend Service 的 定义 文件 


frontend-service. yaml: 


apiVersion: v1 
kind: Service 
metadata: 
name: frontend 
labels: 
name: frontend 
spec: 
ports: 
# the port that this service should serve on 
- port: 80 
selector: 


name: frontend 


通过 定义 文件 创建 Frontend Service: 


$ kubectl create -f frontend-service.yaml 


service "frontend" created 


A 14] Frontend Service: 


$ kubectl get service frontend 
NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELECTOR 


frontend 10.254.69.78 <none> 80/TCP name=fro 


3.5 ”设置 Guestbook 外 网 访问 


至 此 Guestbook 就 已 经 运行 在 Kubernetes 上 ， 但 是 还 有 一 件 很 重要 的 
事情 要 和 解决， 用户 该 如 何 访问 Guestbook Frontend 呢 ? 是 否 通过 Frontend 
Service 的 虚拟 IP 10.254.69.78? 但 是 Service 的 虚拟 IP 是 由 Kubernetes 虚 拟 
出 来 的 内 部 网 络 ， 而 外 部 网 络 是 无 法 寻 址 到 的 ， 这 时 候 就 需要 增加 一 层 
网 络 转发 ， 即 外 网 到 内 网 的 转发 。 实 现 方 式 有 很 多 种 ， 我 们 这 里 采用 一 
种 叫 作 NodePort 的 方式 来 实现 。 即 Kubernetes 将 会 在 每 个 Node 上 设置 端 
口 ， 称 为 NodePort， 通 过 NodePort 端 口 可 以 访问 到 Pod。 

















修改 Frontend Service 的 定义 文件 frontend-service.yaml， 设 置 
spec.type 为 NodePort: 


apiVersion: v1 
kind: Service 
metadata: 
name: frontend 
labels: 
name: frontend 
spec: 
type: NodePort 
ports: 
# the port that this service should serve on 
- port: 80 
selector: 


name: frontend 


重新 创建 Frontend Service: 


$ kubectl replace -f frontend-service.yaml --force 


You have exposed your service on an external port on all nodes in 
cluster. If you want to expose this service to the external inte 


need to set up firewall rules for the service port(s) (tcp:31505) 


See http://releases.k8s.i0/release-1.1/docs/user -guide/services-f 
details. 


service "frontend" created 


Frontend Service 创 建成 功 信息 中 说 明了 已 经 创建 NodePort 
(tcp:31505)， 那 么 通过 任何 一 个 Node 的 IP 和 NodePort (tcp:31505) 即 可 访 
问 到 Guestbook ”Frontend。 然 后 在 界面 的 输入 框 中 输入 任意 字符 串 并 提 
交 ， 字 符 串 将 会 被 保存 并 显示 在 最 下 方 ， 如 网 3-2 所 示 。 











a 14 i x 5s = = 
Guestbook 


Life is good 
Live in the moment 


The worid is his who enjoys it 
Joy 











图 3-2 Guestbook 界面 


3.6 ”清理 Guestbook 


清理 Guestbook， 只 需要 分 别 删除 创建 出 的 Replication Controller 和 


Service: 


$ kubectl delete replicationcontroller redis-master redis-slave f 
replicationcontroller "redis-master" deleted 
replicationcontroller "redis-slave" deleted 


replicationcontroller "frontend" deleted 


$ kubectl delete service redis-master redis-slave frontend 
service "redis-master" deleted 
service "redis-slave" deleted 


service "frontend" deleted 


第 4 章 
Pod 


Pod 是 Kubernetes 的 基本 操作 单元 ， 也 是 应 用 运行 的 载体 。 整 个 
Kubernetes 系 统 都 是 围绕 着 Pod 展 开 的 ， 比 如 如 何 部 署 运 行 Pod、 如 何 保 
证 Pod 的 可 靠 性 、 如 何 访 问 Pod 等 。 男 外 ，Pod 是 一 个 或 多 个 相关 容器 的 

合 ， 这 可 以 说 是 一 大 创新 点 ， 提 供 了 一 种 容器 组 合 的 模型 ， 当 然 也 使 
得 在 Pod 的 操作 和 生命 周期 管理 上 稍 有 有 不同。 本章 将 围 经 Pod 进 行 详细 讲 
解 ， 首 先 介绍 如 何 运行 一 个 最 基本 的 Pod， 然 后 由 浅 入 深 地 说 明 Pod 的 各 
个 方面 ， 包 括 资 源 隔 离 、 网 络 、 生 命 周 期 管理 和 调度 。 





4.1 际 惯例 的 Hello World 


不 免 俗 地 我 们 也 将 以 Hello ”World 作 为 开始 ， 创 建 一 个 简单 的 Hello 
World Pod， 运 行 一 个 输出 “Hello World” 的 容器 ，Hello World Pod 的 定义 
文件 hello-world-pod.yaml: 


apiVersion: v1 
kind: Pod 
metadata: 
name: hello-world 
spec: 
restartPolicy: OnFailure 


containers: 


- name: hello 
image: "ubuntu:14.04" 


command: ["/bin/echo", "Hello", "World" | 





定义 文件 中 描述 了 Pod 的 属性 和 行为 ， 其 中 的 主要 要 素 如 下 所 示 。 
。apiVersion: 声明 Kubermetes 的 API 版 本 ， 目 前 是 v1。 
“kind: 声明 API 对 象 的 类 型 ， 这 里 类 型 是 Pod。 
e metadata: 设置 Pod 的 元 数据 。 
e name: 指定 Pod 的 名 称 ，Pod 名 称 必须 在 Namespace 内 唯一 。 
e spec: 配置 Pod 的 具体 规格 。 
。restartPolicy: 设置 Pod 的 重启 策略 。 


e containers: 设置 Pod 中 容器 的 规格 ， 数 组 形式 ， 每 一 项 定义 


name: 指定 容器 的 名 称 ， 在 Pod 的 定义 中 唯一 。 
image: 设置 容器 镜像 。 
command: 设置 容器 的 启动 命令 


Hello World Pod 的 定义 中 设置 了 一 个 容器 ， 名 称 是 hello， 使 用 镜像 
ubuntu:14.04， 同 时 启动 命令 ee "Hello","World"]， 实 际 上 这 
类 似 我 们 使 用 docker run 命 令 运 行 容器 : 


$ docker run --name hellop ubuntu:14.04 /bin/echo Hello World 
Hello World 


需要 注意 的 是 ， 因 为 容器 输出 完 Hello World 就 会 退出 ， 这 是 一 次 性 
执行 的 ， 所 以 在 Pod 的 定义 中 ，.spec.restartPolicy 设 置 为 OnFailure， 即 在 
容器 正常 退出 的 情况 下 不 会 重新 创建 容器 。 


通过 定义 文件 创建 Hello World Pod: 


$ kubectl create -f hello-world-pod.yaml 


pod "hello-world" created 


创建 成 功 后 ， 可 以 查询 Hello World Pod: 


$ kubectl get pod hello-world 


NAME READY STATUS RESTARTS AGE 
hello-world 0/1 ExitCode:0 0 1m 
然后 可 以 查询 Pod 输 出 : 


$ kubectl logs hello-world 
Hello World 


最 后 删除 Hello World Pod: 


$ kubectl delete pod hello-world 
pod "hello-world" deleted 


4.2 Pod 的 基本 操作 


4.2.1 创建 Pod 


4.1 节 中 我 们 使 用 kubectl create 命令 创建 了 Pod，Kubernetes 中 大 部 分 
API 对 象 都 是 通过 kubectl create 命 令 创建 的 。 


如 果 Pod 的 定义 存在 错误 ，kubect create 会 打印 错误 信息 ， 现 有 一 个 
Pod 的 错误 定义 文件 error-pod.yaml: 


apiVersion: v1 


kind: Pod 
metadata: 
spec: 


restartPolicy: Maybe 
containers: 
- name: hello 

image: "ubuntu:14.04" 


entrypoint : ["/bin/echo","Hello", "World" ] 


通过 定义 文件 创建 Pod， 将 会 创建 失败 并 提示 相应 的 错误 信息 : 


$ kubectl create -f error-pod.yaml 


The Pod "" is invalid. 


* metadata.name: required value, Details: name or generateName i: 


* spec.restartPolicy: unsupported value 'Maybe', Details: support 


4.2.2 ”查询 Pod 





最 常用 的 查询 命令 就 是 kubect get， 可 以 查询 一 个 或 者 多 个 Pod 的 信 


T, MEAW Pod: 


$ kubectl get pod my-pod 
NAME READY STATUS RESTARTS AGE 


my - pod 1/1 Running 0 10s 





查询 显示 的 字段 含义 如 下 所 示 。 
。NAME: Pod 的 名 称 。 


。 READY: Pod 的 准备 状况 ， 右 边 的 数字 表示 Pod 包 含 的 容器 总 数 
目 ， 左 边 的 数字 表示 准备 就 绪 的 容器 数目 。 


。STATUS: Pod 的 状态 。 
。RESTARTS: Pod 的 重启 次 数 。 


e AGE: Pod 的 运行 时 间 。 





其 中 Pod 的 准备 状况 指 的 是 Pod 是 否 准 备 就 绪 以 接收 请 求 ，Pod 的 准 
备 状 况 取决 于 容器 ， 即 所 有 容器 都 准备 就 绪 了 ，Pod 才 准备 就 绪 。 这 时 
候 Kubernetes 的 代理 服务 才 会 添加 Pod 作 为 分 发 后 端 ， 而 一 旦 Pod 的 准备 
状况 变 为 false( 至 少 一 个 容器 的 准备 状况 变 为 false)，Kubermetes 会 将 
Pod 从 代理 服务 的 分 发 后 端 移 除 ， 即 不 会 分 发 请 求 给 该 Pod。 

默认 情况 下 ，kubectl get 只 是 显示 Pod 的 简要 信息 ， 以 下 方式 可 用 于 
获取 Pod 的 完整 信息 : 


$ kubectl get pod my-pod --output json # 用 JSON 格 式 显 示 Pod 的 完整 信息 


a 
H A 


$ kubectl get pod my-pod --output yaml # 用 YAML 方 式 显 示 Pod 的 完整 信 





另外 ，kubectl get 支 持 以 Go Template 方 式 过 滤 出 指定 的 信息 ， 比 如 
查询 Pod 的 运行 状态 : 


$ kubectl get pods my-pod --output=go-template --template={{.stat 


Running 


另 一 个 命令 kubectl describe 支 持 查 询 Pod 的 状态 和 生命 周期 事件 : 


$ kubectl describe pod my-pod 
Name: my -pod 

Namespace: default 

Image(s): nginx 

Node: kube-node-2/192.168.3.148 


Start Time: Sun, 22 Nov 2015 18:00:34 +0800 


Labels: <none> 
Status: Running 
Reason: 
Message: 
IP: 10.0.62.37 


Replication Controllers: <none> 
Containers: 
container1: 

Container ID: 

docker ://60387df7e5f2c781ed508084f fa3579F05482c6b465abb3d4fcaeda 
Image: nginx 
Image ID: 

docker ://6886fb5a9b8d73b12d842bab8f9a6941c36094c2974abddb685d54c 


State: Running 


Started: Sun, 22 Nov 2015 18:00:42 


Ready: True 
Restart Count: 0 
Environment Variables: 
Conditions: 
Type Status 
Ready True 


Volumes: 


Events: 





查询 显示 的 字段 含义 如 下 所 示 。 
。Name: Pod 的 名 称 。 
。Namespace: Pod 的 Namespace。 
e Image(s): Pod 使 用 的 镜像 。 

e Node: Pod 所 在 的 Node。 

。Start Time: Pod 的 起 始 时间 。 
。Labels: Pod 的 Label。 

。Status: Pod 的 状态 。 


e Reason: Pod 处 于 当前 状态 的 原因 。 


+0800 


。Message: Pod 处 于 当前 状态 的 信息 。 

° IP: Pod 的 PodIP。 

。Replication Controllers: Pod 对 应 的 Replication Controller。 
e Containers: Pod 中 容器 的 信息 。 


。Container ID: 容器 的 ID。 

-e Image: 容器 的 镜像 。 

。Image ID: 镜像 的 ID。 

° State: BARIS. 

° Ready: 容器 的 准备 状况 〈true 表 示人 准备 就 绪 ) 。 
e Restart Count: 容器 的 重 局 次 数 统计 。 
。Environment Variables: 容 堪 的 环境 变量 。 


e Conditions: Pod 的 条 件 ， 包 含 Pod 的 准备 状况 (true 表 示人 准备 就 
2) 


e Volumes: Pod 的 数据 卷 。 
。Events: 与 Pod 相 关 的 事件 列表 。 


4.2.3 删除 Pod 


可 以 通过 kubectl delete 命 令 删 除 Pod: 


$ kubectl delete pod my-pod 


另外 ，kubectl delete 命 令 可 以 批量 删除 全 部 Pod: 


$ kubectl delete pod --all 


4.2.4 更 新 Pod 


Pod 在 创建 之 后 如 果 和 希望 更 新 Pod， 可 以 在 修改 Pod 的 定义 文件 后 执 


/一 


ÎT: 


$ kubectl replace /path/to/my-pod.yaml 





但 是 因为 Pod 的 很 多 属性 是 没 办 法 修改 的 ， 比 如 容器 镜像 ， 这 时 候 
可 以 通过 kubectl replace 命 令 设 置 --force 参 数 ， 等 效 于 重建 Pod。 


4.3 Pod 与 容器 





在 Docker 中 ， 容 器 是 最 小 处 理 单位 ， 增 删改 查 的 对 象 是 容器 ， 容 器 
是 一 种 虚拟 化 技术 ， 容 器 之 间 是 隔离 的 ， 隔 离 是 基于 Linux Namespace 
实现 的 ，Linux 内 核 中 提供 了 6 种 Linux Namespace 隔 离 的 系统 调用 ， 如 表 
4-1 所 示 。 


表 4-1 Linux Namespace 


Linux Namespace 系统 调用 参数 隔离 内 容 

UTS CLONE_NEWUTS 主机 名 与 域名 

IPC CLONE_NEWIPC 结 号 量 、 消 息 队 列 和 共享 内 存 
PID CLONE_NEWPID 进程 编号 

Network CLONE_NEWNET 网 络 设 备 、 网 络 栈 、 端 口 等 
Mount CLONE_NEWNS 挂 载 点 《文件 系统 ) 

User CLONE_NEWUSER 户 和 用 户 组 




































































而 在 Kubernetes 中 ，Pod 包 含 一 个 或 者 多 个 相关 的 容器 ，Pod 可 以 认 
为 是 容器 的 一 种 延伸 扩展 ， 一 个 Pod 也 是 一 个 隔离 体 ， 而 Pod 包 含 的 一 组 
容器 又 是 共享 的 〈 当 前 共享 的 Linux Namespace 包 括 : PID. Network, 
IPC 和 UTS)〉。 除 此 之 外 ，Pod 中 的 容器 可 以 访问 共同 的 数据 卷 来 实现 文 
件 系统 的 共享 ， 所 以 Kubernetes 中 的 数据 卷 是 Pod 级 别 的 ， 而 不 是 容器 级 
别 的 。 








Pod 是 容 圳 的 集合 ， 容 圳 是 真正 的 执行 体 。 相 比 原 生 的 容器 接口 ， 
Pod 提 供 了 更 高 层次 的 抽象 ， 但 是 Pod 的 设计 并 不 是 为 了 运行 同一 个 应 用 
的 多 个 实例 ， 而 是 运行 一 个 应 用 多 个 紧密 联系 的 程序 。 而 每 个 程序 运行 
在 单独 的 容器 中 ， 以 Pod 的 形式 组 合成 一 个 应 用 。 相 比 于 在 单个 容 融 中 
运行 多 个 程序 ， 这 样 的 设计 有 以 下 好 处 。 





“透明 性 : 将 Pod 内 的 容器 同 基 础 设施 可 见 ， 撒 层 系统 就 能 器 容 器 提 
供 如 进程 管理 和 资源 监控 等 服务 ， 这 样 能 给 用 户 融 来 极 大 便利 。 


© 解 绑 软 件 的 依赖 : 这 样 单 个 容器 可 以 独立 地 重建 和 重新 部 车， 可 
以 实现 独立 容器 的 实时 更 新 。 














。 SAE: 用 户 不 需要 运行 目 己 的 进程 管理 侨 ， 也 不 需 负责 信号 量 
和 退出 码 的 传递 等 。 





* 局 效 性 ， 因 为 底层 设备 负责 更 多 的 管理 ， 容 右 因 而 能 更 轻 量 化 。 





在 Pod 中 可 以 详细 地 配置 如 何 运行 一 个 容器 ， 就 像 我 们 使 用 docker 
run 命 令 运行 容 絮 一 样 ， 接 下 来 结合 实例 说 明 如 何在 Pod 中 定义 容器 。 


4.3.1 镜像 


运行 容 右 必须 先 指 定 镜像 ， 镜 像 的 名 称 则 遵循 Docker 的 命名 规范 。 
运行 容器 前 需要 本 地 存在 对 应 的 镜像 ， 如 果 镜 像 不 存在 ， 会 从 Docker 镜 
像 仓 库 下 载 。Kubernetes 中 可 以 选择 镜像 的 下 载 策 略 ， 支 持 的 策略 如 
"Ps 





e Always: 每 次 都 下 载 最 新 的 镜像 。 
e Never: 只 使 用 本 地 镜像 ， 从 不 下 载 。 
。IfNotPresent: 只 有 当 本 地 没有 的 时 候 才 下 载 镜 像 。 





Kubernetes Node 是 容器 运行 的 宿主 机 ，Pod 被 分 配 到 Node 之 后 ， 会 
根据 镜像 下 载 集 略 选择 是 否 下 载 镜 像 。 有 时 候 网 络 下 载 是 一 个 较 大 的 开 
销 ， 可 以 根据 需要 自行 选择 策略 ， 但 是 无 论 如 何 要 确保 镜像 在 本 地 或 者 
镜像 仓库 存在 ， 人 否则 Pod 无 法 运行 。 








Pod 定 义 中 一 个 容 需 镜像 的 配置 示例 如 下 所 示 : 


name: hello 
image: "ubuntu:14.04" 


imagePullPolicy: Always 


Docker 镜 像 仓 库 也 称 为 Docker 注 册 服 务 器 (Docker Registry) ， 它 
包括 Docker 公 共 镜 像 仓库 (Docker Hub) 和 私有 镜像 仓库 。 


例如 对 于 ubuntu:14.04， 它 实际 上 每 效 于 docker.io/ubuntu:14.04， 即 
从 Docker 公 共 镜 像 仓 库 下 载 镜像 。 而 对 于 myregistry.com/ubuntu:14.04 来 
说 ，myregistry.com 是 Docker 私 有 镜像 仓库 地 址 ， 即 从 myregistry.com 下 
载 镜像 。 





使 用 Docker 私 有 镜像 仓库 ， 往 往 需要 进行 认证 。 一 种 方法 是 在 所 有 
的 Node 上 手工 操作 docker login [registry] 进 行 登录 认证 ; 另 一 种 方法 是 在 
Pod 中 添加 Image Pull Secret 用 于 认证 ，Image Pull ” Secret 是 一 种 
kubernetes.io/dockercfg 类 型 的 Secret，Kubernetes 用 来 进行 Docker 镜 像 仓 


库 的 认证 ， 具 体操 作 方 法 如 下 所 示 。 
1. 首先 登录 Docker 私 有 注册 服务 器 ,例如 myregistry.com: 


$ docker login myregistry.com 

WARNING: The Auth config file is empty 

Username: admin 

Password: 

Email: wlh6666@qq.com 

WARNING: login credentials saved in /root/.dockercfg. 


Login Succeeded 


登录 成 功 后 ，Docker 会 生成 一 个 文件 .dockercfg: 


$ echo $(cat ~/.dockercfg) 


{ "myregistry.com": { "auth": "d2F1lYWRtawW46d2F1QDEyMw==", 


2. 使 用 Base64 编 码 .dockercfg 内 容 : 


$ export DOCKER CFG DATA= cat ~/.dockercfg | base64- 


根据 编码 后 的 内 容 创 建 Image Pull Secret 的 定义 文件 : 


$ cat > ./image-pull-secret.yaml <<EOF 
apiVersion: v1 


kind: Secret 


"email' 


metadata: 

name: myregistrykey 
data: 

.dockercfg: ${DOCKER_CFG_DATA} 
type: kubernetes.io/dockercfg 


EOF 


通过 定义 文件 创建 Image Pull Secret: 


$ kubectl create -f ./image-pull-secret.yaml 


secret "myregistrykey" created 


然后 在 Pod 的 定义 中 通过 .spec.imagePullSecrets ”添加 Image 


Secret: 


apiVersion: v1 
kind: Pod 
metadata: 
name: redis 
spec: 
containers: 
- name: redis 
image: myregistrykey.com/redis 
restartPolicy: Always 
imagePullSecrets: 


- name: myregistrykey 


Pull 


提示 


系统 管理 员 可 以 设置 全 局 的 Image Pull Secret， 创 建 Pod 的 时 候 





会 自动 添加 上 Image Pull Secret。 这 样 一 来 就 不 需要 每 个 Pod 显 示 配 
置 ， 可 参考 10.3.3 贡 。 





4.3.2 ”启动 命令 


启动 命令 用 来 说 明 容 器 是 如 何 运行 的 ， 在 Pod 的 定义 中 可 以 设置 容 
器 启动 命令 和 参数 ，4.1 节 中 的 Hello World Pod 就 对 容器 设置 了 启动 命 


apiVersion: v1 
kind: Pod 
metadata: 
name: hello-world 
spec: 
restartPolicy: Never 
containers: 
- name: hello 
image: "ubuntu:14.04" 


command: ["/bin/echo", "Hello", "World" | 


Fb, earl a Nar tA] VACA: 


command: ["/bin/echo" | 


args: ["Hello", "World" | 





在 使 用 docker runm GZT RARR, MRA EAH AB 
命令 ， 容 右 则 使 用 Docker 镜 像 默 认 的 局 动 命令 。 这 一 般 是 通过 
Dockerfile 中 的 CMD 和 ENTRYPOINT 进 行 设置 的 ， 这 是 非常 容易 混淆 的 
两 个 概念 ， 假 设 镜像 image1l 的 Dockerfile 声 明 CMD 命 令 如 下 : 








ROM ubuntu 


CMD ["echo"] 
运行 容器 : 


$ docker run image1 echo hello 


hello 


另 一 个 镜像 image2 的 Dockerfile 声 明 ENTRYPOINT 命 令 如 下 : 


FROM Ubuntu 


ENTRYPOINT ["echo"] 
运行 容器 : 


$ docker run image2 echo hello 


echo hello 





从 不 例 中 可 以 看 出 ，CMD 命 令 是 可 徐 盖 的 ，docker run 指 定 的 局 动 





命令 会 把 CMD 设 置 的 命令 履 盖 。 而 ENTRYPOINT 设 置 的 命令 只 是 一 了 
入 口 ，docker run 指 定 的 局 动 命令 作为 参数 传递 给 ENTRYPOINT 设 置 的 
Ly A 

x 


TE, MAERT ER. 


五 
a 


在 Pod 的 定义 中 ，command 和 args 都 是 可 选项 ， 


将 和 Docker 镜 像 的 





ENTRYPOINT 和 CMD 相 互 作用 ， 生 成 最 终 容器 的 启动 命令， 具 


如 下 所 示 : 


。 如 果 容 器 没有 指定 command 和 args， 则 容器 使 用 镜像 的 
ENTRYPOINT 和 CMD 作 为 启动 命令 运行 。 


。 如果 容 右 指定 了 command， 而 没有 指定 args， 则 容器 忽略 镜像 的 











ENTRYPOINT 和 CMD， 使 用 指定 的 command 作 为 启动 命令 运行 。 





。 ”如 果 容 器 没有 指定 command， 只 是 指定 了 args， 容 右 将 使 用 镜像 





的 ENTRYPOINT 和 CMD 作 为 启动 命令 运行 。 


。 了 command 和 args， 则 容 右 使 用 command 和 args 作 为 


启动 命令 运 


表 4-2 枚 举 了 4 条 规则 的 相应 示例 。 


镜像 ENTRYPOINT 


镜像 CMD 


容器 command 


容器 args 


最 终 启 动 命令 





[/ep-1] 


[foo bar] 


NULL 


NULL 


[ep-1 foo bar] 





[/ep-1] 


[foo bar] 


[/ep-2] 


NULL 


[ep-2] 





[/ep-1] 


[foo bar] 


<not set> 


[zoo boo] 


[ep-1 zoo boo] 





[/ep-1] 


4.3.3 “环境 变量 





[foo bar] 


Pod 定 义 中 可 以 设置 容 


env: 


<not set> 





器 运行 时 的 环 


[zoo boo] 








[ep-2 zoo boo] 





- name: PARAMETER 1 
value: value_1 
- name: PARAMETER_2 


value: value 2 


对 于 Hello World Pod， 可 以 通过 设置 环境 变量 的 方式 进行 改造 : 


apiVersion: v1 


kind: Pod 


metadata: 


name: hello-world 


spec: 


restartPolicy: Never 


containers: 


称 、 


name: hello 
image: "ubuntu:14.04" 
env: 
- name: MESSAGE 

value: "hello world" 
command: ["/bin/sh", "-c"] 


args: ["/bin/echo \"${MESSAGE}\""] 





在 一 些 场景 下 ，Pod 中 的 容器 希望 获取 本 身 的 信息 ， 比 如 Pod 的 名 
Pod 所 在 的 Namespace 等 。 在 Kubernetes 中 提供 了 Downward API 获 取 
这 些 信息 ， 并 且 可 以 通过 环境 变量 告诉 容器 目前 文 持 的 信息 。 


。Pod 的 名 称 : metadata.name。 


。Pod 的 Namespace: metadata.namespace。 


。Pod 的 PodIP: status.podIP。 





现在 创建 一 个 Pod 并 通过 环境 变量 来 获取 Downward API，Pod 的 定 
义 文 件 downwardapi- env.yaml: 


apiVersion: v1 
kind: Pod 
metadata: 
name: downwardapi-env 
spec: 
containers: 
- name: test-container 
image: ubuntu:14.04 
command: ["/bin/bash","-c","while true; do sleep 5; done" | 
env: 
- name: MY_POD_NAME 
valueFrom: 
fieldRef: 
fieldPath: metadata.name 
- name: MY_POD_NAMESPACE 
valueFrom: 
fieldRef: 
fieldPath: metadata.namespace 
- name: MY_POD_IP 
valueFrom: 


fieldRef: 


fieldPath: status.podIP 


Pod 创 建 运行 后 ， 碍 询 Pod 的 和 输出， 过滤 出 配置 的 3 个 环境 变量 : 


$ kubectl exec downwardapi-env env|grep MY_POD 
MY_POD_NAME=downwardapi-env 
MY_POD_NAMESPACE=default 

MY_POD_IP=10.0.10.103 


4.3.4 vig A 


在 使 用 docker run 运 行 容 器 的 时 候 往往 通过 --publish/-p 参 数 设置 端口 
映射 规则 ， 同 样 的 ， 可 以 在 Pod 的 定义 中 设置 容器 的 端口 映射 规则 ， 比 
如 下 面 这 个 Pod 的 设置 容器 nginx 的 端口 映射 规则 为 0.0.0.0:80->80/TCP: 


apiVersion: v1 
kind: Pod 
metadata: 

name: my-nginx 

spec: 
containers: 

- name: nginx 
image: nginx 
ports: 

- name: web 
containerPort: 80 


protocol: TCP 


hostIP: 0.0.0.0 


hostPort: 80 


在 Pod 的 定义 中 ， 通 过 .spec.containers[].ports[] 设 置 容器 的 端口 ， 数 
组 形式 ， 每 一 项 的 参数 如 下 所 示 。 


name: 设置 端口 名 称 ， 必 须 在 Pod 内 唯一 ， 当 只 配置 一 个 端口 的 
时 候 ， 这 是 一 个 可 选项 ， 当 配置 多 个 端口 的 时 候 ， 这 是 一 个 必 选 项 。 


containerPort: 必 选 项 ， 设 置 在 容器 内 的 端口 ， 有 效 值 范 围 为 
0~65536 〈 不 包括 0 和 65536) 。 


protocol: 可 选项 ， 设 置 端 口 的 协议 ，TCP 或 者 UDP， 默 认 是 
TCP. 


。hostIP: ÆW, KEE EVLEMIP, BRU She SATA By AIP 
接口 上 ， 即 0.0.0.0。 





。hostPort: 可 选项 ， 设 置 在 宿主 机 上 的 端口 ， 如 果 设 置 则 进行 端口 
映射 ， 有 效 值 范围 为 0~ 65536 (不 包括 0 和 65536)。 





使 用 答 主 机 端口 需要 考虑 问 口 冲突 问题 ， 幸 运 的 是 ，Kubernetes 在 
调度 Pod 的 时 候 ， 会 检查 宿主 机 端口 是 否 冲突 。 比 如 两 个 Pod 都 需要 使 用 
答 主 机 端口 80， 那 么 调度 的 时 候 就 会 将 这 两 个 Pod 调 度 到 不 同 Node 上 。 
不 过 ， 如 果 所 有 Node 的 端口 都 被 占用 了 ， 那 么 Pod 调 上 度 会 失败 。 


4.3.5 ”数据 持久 化 和 共享 


容器 是 临时 存在 的 ， 如 果 容 器 被 销毁 ， 容 器 中 的 数据 将 会 丢失 。 为 
了 能 够 持久 化 数据 以 及 共享 容器 间 的 数据 ，Docker 提 出 了 数据 卷 
(Volume) 的 概念 。 简 单 来 说 ， 数 据 卷 就 是 目录 或 者 文件 ， 它 可 以 绕 
过 默认 的 联合 文件 系统 ， 而 以 正常 的 文件 或 者 目录 的 形式 存在 于 宿主 机 
Rag 











在 使 用 docker run 运 行 容 器 的 时 候 ， 我 们 经 各 使 用 参数 --volume/-v 创 
建 数据 卷 ， 即 将 宿主 机 上 的 目录 或 者 文件 挂 载 到 容器 中 。 即 使 容器 被 销 
毁 ， 数 据 卷 中 的 数据 仍然 保存 在 宿主 机 上 。 








一 方面 ， 在 Kubernetes 中 对 Docker 数 据 卷 进行 了 扩展 ， 文 持 对 接 第 
三 方 存储 系统 。 另 一 方面 ，Kubernetes 中 的 数据 卷 是 Pod 级 别 的 ，Pod 中 
的 容器 可 以 访问 共同 的 数据 卷 ， 实 现 容器 间 的 数据 共享 。 





我 们 再 次 对 Hello World Pod 进 行 改 造 。 在 Pod 中 声明 创建 数据 卷 ， 
Pod 中 的 两 个 容器 将 共享 数据 卷 ， 容 器 write 写 入 数据 ， 容 器 hello 读 出 数 
据 ，Hello World Pod 的 定义 文件 hello-world-pod.yaml: 


apiVersion: v1 
kind: Pod 
metadata: 
name: hello-world 
spec: 
restartPolicy: Never 
containers: 
- name: write 
image: "ubuntu:14.04" 


command: ["bash","-c","echo \"Hello World\" >> /data/hello" | 


volumeMounts: 
- name: data 
mountPath: /data 


name: hello 


image: "ubuntu:14.04" 
command: ["bash", "-c","sleep 10; cat /data/hello"] 
volumeMounts: 
- name: data 
mountPath: /data 
volumes: 
- name: data 
hostPath: 


path: /tmp 


可 以 看 到 在 Pod 定 义 中 ，.spec.volumes 配 置 了 一 个 名 称 为 data 的 数据 
卷 ， 数 据 卷 的 类 型 是 hostPath， 使 用 宿主 机 的 目录 /tmp。Pod 中 的 两 个 容 
器 都 通过 .spec.containers[]，volumeMounts 来 设置 挂 载 数据 卷 到 容器 中 的 
路 径 /data。 容 器 write 将 往 /data/hello 写 入 “Hello World”， 容 器 hello 等 待 一 
会 儿 ， 然 后 读 取 文 件 /data/hello 的 数据 显示 ， 即 输出 “Hello World”。 这 样 
一 来 就 实现 了 两 个 容 占 的 数据 共享 。Kubernetes 数 据 卷 提供 了 非常 丰富 
的 持久 化 支持 ， 详 情 可 参考 7.3 市 。 


44 Pod 的 网 络 


Pod 中 的 所 有 容器 网 络 都 是 共享 的 ， 一 个 Pod 中 的 所 有 容器 中 的 网 络 
一 人 致 的 ， 它 们 能 够 通过 本 地 地 址 Cocalhost) 访问 其 他 用 户 容器 的 端 








在 Kubernetes 网 络 模型 中 ， 每 一 个 Pod 都 拥有 一 个 局 平 化 共享 网 络 命 
名 空间 的 IP， 称 为 PodIP。 通 过 PodIP，Pod 就 能 够 跨 网 络 与 其 他 物理 机 
和 容器 进行 通信 。 


在 Pod 运 行 后 ， 我 们 可 以 查询 Pod 的 PodIP: 


$ kubectl get pod my-app --template={{.status.podIP}} 
10.0.10.204 


这 是 一 个 10.0.10.0/24 网 段 的 IP， 实 际 上 这 是 由 Docker 为 容器 进行 网 
络 虚 拟 化 隔离 而 分 配 的 内 部 IP。 也 可 以 设置 Pod 为 Host 网 络 模式 ， 即 直 
接 使 用 宿主 机 的 网 络 ， 不 进行 网 络 虚 拟 化 隔离 。 这 样 一 来 ，Pod 中 的 所 
有 容器 就 直接 骏 露 在 宿主 机 的 网 络 环境 中 ， 这 时 候 ，Pod 的 PodIP 就 是 其 
所 在 Node 的 IP。 








下 面 定 义 的 Pod 设 置 为 Host 网 络 模式 (.spec.hostNetwork=true) : 


apiVersion: v1 
kind: Pod 
metadata: 
name: my-app 
spec: 
containers: 
- name: app 
image: nginx 
ports: 


- name: web 


containerPort: 80 
protocol: tcp 


hostNetwork: true 


使 用 Host 网 络 模式 需要 特别 注意 ， 一 方面 ， 因 为 不 存在 网 络 隔离 ， 
容易 发 生 端口 冲突 ; 另 一 方面 ，Pod 可 以 直接 访问 宿主 机 上 的 所 有 网 络 
设备 和 服务 ， 从 安全 性 上 来 说 这 是 不 可 控 的 。 


4.5 Pod 的 重启 策略 


Pod 的 重启 朱 略 指 的 是 当 Pod 中 的 容器 终止 退出 后 ， 重 局 容器 的 筑 
略 。 需 要 注意 的 是 ， 因 为 Docker 容 器 的 轻 量 级 ， 重 局 容 莫 的 做 法 实际 上 
是 直接 重建 容 姻 ， 有 所 以 容器 中 的 数据 将 会 丢失 ， 如 有 需要 持久 化 的 数 
据 ， 那 么 需要 使 用 数据 卷 进 行 持久 化 设置 。 








重启 策略 是 通过 Pod 定 义 中 的 .spec.restartPolicy 进 行 设置 的 ， 目 前 文 
持 以 下 3 种 策略 。 


e Always: 当 容 器 终止 退出 后 ， 总 是 重 局 容器 ， 默 认 策 略 。 
。OnFailure: 当 容 器 终止 民营 退出 《退出 码 非 0) 时 ， 才 重启 容器 。 
。Never: 当 容 器 终止 退出 时 ， 从 不 重启 容器 。 


现在 创建 一 个 Pod， 其 中 的 容 絮 将 异常 退出 (exit 1) ， 而 Pod 的 重 
局 策略 为 OnFailure，Pod 的 定义 文件 on-failure-restart-pod.yaml; 


apiVersion: v1 


kind: Pod 
metadata: 
name: on-failure-restart-pod 
spec: 
containers: 
- name: container 
image: ubuntu:14.04 
command: ["bash","-c", "exit 1"] 


restartPolicy: OnFailure 


通过 定义 文件 创建 Pod: 


$ kubectl create -f on-failure-restart-pod.yaml 


pods/on-failure-restart-pod 


Pod 创 建成 功 后 ， 一 段 时 间 后 查询 Pod: 


$ kubectl get pod on-failure-restart-pod 
NAME READY STATUS RESTARTS AGE 


on-failure-restart-pod 0/1 Error 3 2m 


在 Pod 的 查询 信息 中 ， 属 性 RESTARTS 的 值 为 3， 说 明 Pod 中 的 容器 
已 经 重启 ， 可 以 分 别 查询 每 个 容器 的 重启 次 数 ， 


$ kubectl get pod on-failure-restart-pod \ 
--template="{{range .status.containerStatuses}}{{.name}}:{{.resta 


container:3 


提示 


关于 Pod 中 容器 的 重启 次 数 统 计 ， 实 际 上 并 不 是 非常 精确 ， 只 能 
作为 一 个 参考 。 首先 它 获取 Pod 所 在 Node 的 所 有 容器 包括 运行 和 
停止 的 ) 作为 统计 基数 ， 所 以 如 宁 将 退出 容 需 进行 清理 〈 可 能 是 人 工 
删除 ， 另 外 Kubelet 会 根据 配置 定时 进行 清理 ) ， 将 会 减少 统计 的 基 





4.6 Pod 的 状态 和 生命 周期 


46.1 ZJARA 





Pod 的 本 质 是 一 组 容器 ，Pod 的 状态 便 是 容 堪 状态 的 体现 和 概括 ， 同 
时 容器 的 状态 变化 会 影响 Pod 的 状态 变化 ， 触 发 Pod 的 生命 周期 阶段 转 
换 。 


在 使 用 docker ”run 运行 容器 的 时 候 ， 首 先 会 下 载 容器 镜像 。 下 载 成 
功 后 运行 容器 ， 当 容器 运行 结束 退出 后 (包括 正常 和 异常 退出 ) ， 容 器 
终止 ， 这 是 一 个 容器 的 生命 周期 过 程 。 相 应 的 ，Kubernetes 中 对 于 Pod 中 
的 容器 进行 了 状态 的 记录 ， 其 中 每 种 状态 下 包含 的 信息 如 下 所 示 。 





e Waiting: 容器 正在 等 竺 创建， 比如 正在 下 载 镜像 。 


。Reason: 等 待 的 原因 。 


e Running: 容 吉 已 经 创建 ， 并 且 正 在 运行 。 
。startedAt: 容器 创建 时 间 。 
e Terminated: 容器 终止 退出 。 


。exitCode: 退出 码 。 

e signal: 容器 退出 信号 。 

e reason: 容器 退出 原因 。 

e message: 容器 退出 信息 。 
。startedAt: 容器 创建 时 间 。 
e finishedAt: 容器 退出 时 间 。 
。containerID: 容器 的 ID。 


Pod 运 行 后 ， 可 以 查询 其 中 容器 的 状态 : 


$ kubectl describe pod my-pod 


Containers: 
container1: 

Container ID: 

docker ://60387df7e5f2c781ed508084f fa3579F05482c6b465abb3d4fcae0a 
Image: nginx 
Image ID: 

docker ://6886fb5a9b8d73b12d842bab8f9a6941c36094c2974abddb685d54c 
State: Running 

Started: Sun, 22 Nov 2015 18:00:42 +0800 


Ready: True 


Restart Count: 0 


Environment Variables: 


4.6.2 Pod 的 生命 周期 阶段 


Pod 的 生命 周期 可 以 简单 描述 为 : 首先 Pod 补 创建， 紧 接 着 Pod 被 调 
度 到 Node 进 行 部 晋 运行 。Pod 是 非常 忠诚 的 ， 一 旦 被 分 配 到 Node 后 ， 就 
不 会 离开 这 个 Node， 直 到 它 被 删除 ， 生 命 周期 完结 


Pod 的 生命 周期 被 定义 为 以 下 几 个 阶段 。 


Pending: Pod 已 经 被 创建 ， 但 是 一 个 或 者 多 个 容器 还 未 创建 ， 这 
包括 Pod 调 度 阶段 ， 以 及 容器 镜像 的 下 载 过 程 。 


。 Running: Pod 已 经 被 调度 到 Node， 上 所 有 容器 已 经 创建 ， 并 且 至 少 
一 个 容器 在 运行 或 者 正在 重 局 。 





。Succeeded: Pod 中 所 有 容器 正常 退出 。 








。Failed: Pod 中 所 有 容器 退出 ， 至 少 有 一 个 容器 是 一 次 退出 的 。 
可 以 查询 Pod 处 于 生命 周期 的 哪个 阶段 : 


$ kubectl get pods my-app --template="{{.status.phase}}" 


Running 


Pod 被 创建 成 功 后 ， 首 先 会 进入 Pending 阶 段 ， 然 后 被 调度 到 Node 后 
运行 ， 进 入 Running 阶 段 。 如 果 Pod 中 的 容器 停止 〈 正 常 或 者 异常 退 





Ht) ， 那 么 Pod 根 据 重 局 策略 的 不 同 会 进入 不 同 的 阶段 ， 举 例如 下 。 
“。Pod 是 Running 阶 段 ， 含 有 一 个 容器 ， 容 器 正常 退出 : 


如 果 重 启 集 略 是 Always， 那 么 会 重启 容器 ，Pod 保 持 Running 阶 

段 。 

如 果 重 启 策略 是 OnFailure，Pod 进 入 Succeeded 阶 段 。 
如 果 重 启 策略 是 Never，Pod 进 入 Succeeded 阶 段 。 


。Pod 是 Running 阶 段 ， 含 有 一 个 容器 ， 容 器 异常 退出 : 


如 果 重 启 集 略 是 Always， 那 么 会 重启 容器 ，Pod 保 持 Running 阶 

段 。 

如 果 重 启 策略 是 OnFailure，Pod 保 持 Running 阶 段 。 
如 果 重 启 策略 是 Never，Pod 进 入 Failed 阶 段 。 


。Pod 是 Running 阶 段 ， 含 有 两 个 容 右 ， 其 中 一 个 容器 异常 退出 : 


如 有 果 重 启 集 略 是 Always， 那 么 会 重启 容器 ，Pod 保 持 Running 阶 

段 。 

如 果 重 局 策略 是 OnFailure，Pod 保 持 Running 阶 段 。 
如 果 重 启 策略 是 Never，Pod 保 持 Running 阶 段 。 


。Pod 是 Running 阶 段 ， 含 有 两 个 容器 ， 两 个 容器 都 异常 退出 : 


如 有 果 重 启 策 略 是 Always， 那 么 会 重启 容器 ，Pod 保 持 Running 阶 

段 。 

如 果 重 局 策略 是 OnFailure，Pod 保 持 Running 阶 段 。 
如 果 重 启 策略 是 Never，Pod 进 入 Failed 阶 段 。 


一 旦 被 分 配 到 Node，Pod 束 不 会 离开 这 个 Node， 直 到 被 删除 。 删 除 
可 能 是 人 为 地 删除 ， 或 者 被 Replication ”Controller 删 除 ， 也 有 可 能 是 当 
Pod 进 入 Succeeded 或 者 Failed 阶 段 过 期 ， 被 Kubernetes 清 理 掉 。 总 之 Pod 
被 删除 后 ，Pod 的 生命 周期 就 算 结束 ， 即 使 被 Replication Controller 进 行 
重建 ， 那 也 是 新 的 Pod， 因 为 Pod 的 ID 已 经 发 生 了 变化 ， 所 以 实际 上 Pod 
迁移 ， 准 确 的 说 法 是 在 新 的 Node 上 重建 Pod。 


4.6.3 生命 周期 回调 函数 


Kubernetes 提 供 了 回调 函数 ， 在 容器 的 生命 周期 的 特定 阶段 执行 调 
用 ， 比 如 容 堪 在 停止 前 希望 执行 菜 项 操作 ， 就 可 以 注册 相应 的 钧 子 函 
数 。 目 前 提供 的 生命 周期 回调 函数 如 下 所 示 。 


“PostStart: 在 容 右 创建 成 功 后 调用 该 回调 函数 。 


。PreStop: 在 容器 被 终止 前 调用 该 回调 函数 。 





钩子 函数 的 实现 方式 有 以 下 两 种 。 


e Exec 


说 明 


在 容 右 中 执行 指定 的 命令 。 
配置 参数 


command: 需要 执行 的 命 字符 串 数组 。 
示例 


exec: 
command: 
- cat 


- /tmp/health 


e HTTP 


说 明 
发 起 一 个 HTTP 调 用 请 求 。 
配置 参数 
path: 请 求 的 URL 路 径 ， 可 选项 。 
port: 请 求 的 端口 ， 必 选项 。 
host: 请 求 的 卫 ， 可 选项 ， 默 认 是 Pod 的 PodIP。 
scheme: 请 求 的 协议 ， 可 选项 ， 默 认 是 HITP。 
示例 


httpGet : 
host: 192.168.1.1 


path: /notify 
port: 8080 


现在 定义 一 个 Pod， 包 含 一 个 Java 的 Web 应 用 容器 ， 其 中 设置 了 
PostStart 和 PreStop 回 调 函 数 。 即 在 容器 创建 成 功 后 ， 复 制 /sample.war 
到 /app 目 录 。 而 在 容器 被 终止 之 前 ， 发 送 HTTP 请 求 到 
http://monitor.com:8080/warning， 往 监控 系统 发 送 一 个 警告 ，Pod 的 定义 
如 下 : 


apiVersion: v1 
kind: Pod 
metadata: 

name: javaweb-2 
spec: 

containers: 


- image: resouer/sample:v2 


name: war 
lifecycle: 
postStart: 
exec: 
command: 
- "cp" 
- "/sample.war" 
- "Zapp" 
preStop: 
httpGet: 


host: monitor.com 


path: /warning 
port: 8080 


scheme: HTTP 


4.7 目 定 义 检查 Pod 


对 于 Pod 是 售 健康 ， 即 Pod 中 的 容器 是 人 否 健 康 ， 默 认 情 况 下 只 是 检查 
容器 是 否 正常 运行 。 但 有 时 候 容 器 正常 运行 不 代表 应 用 健康 ， 有 可 能 应 
用 的 进程 已 经 阻塞 住 无 法 正常 处 理 请 求 ， 所 以 为 了 提供 更 加 健壮 的 应 
用 ， 往 往 需 要 定制 化 的 健康 检查。 











除 此 之 外 ， 有 的 应 用 局 动 后 需要 进行 一 系列 初始 化 处 理 ， 在 初始 化 
完成 之 前 应 用 是 无 法 正常 处 理 请 求 的 。 如 果 应 用 初始 化 需要 较 长 时 间 ， 
而 实际 上 容器 创建 的 时 间 是 可 以 忽略 不 计 的 。 默 认 情 况 下 ，Kubernetes 
发 现 容 器 创建 成 功 并 运行 ， 就 会 认为 其 准备 丈 绕 ， 真 实情 况 是 容器 里 的 
应 用 可 能 还 处 于 初始 化 阶段 ， 无 法 正常 接受 请 求 。 如 果 用 户 访问 就 会 得 
到 错误 啊 应 ， 这 不 是 我 们 希望 看 到 的 情况 。 同 样 的 ， 我 们 需要 更 加 精确 
的 检查 机 制 来 判断 Pod 和 容器 是 否 准备 就 绕 ， 从 而 让 Kubernetes 判 断 是 否 
分 发 请 求 给 Pod。 








针对 这 些 需求 ，Kubernetes 中 提供 了 Probe 机 制 ， 有 以 下 两 种 类 型 的 
Probe。 





。Liveness Probe: 用 于 容器 的 自 定 义 健康 检查 ， 如 果 Liveness Probe 
检查 失败 ，Kubernetes 将 杀 死 容器 ， 然 后 根据 Pod 的 重启 策略 来 决定 是 否 
重启 容器 。 





Readiness Probe: 用 于 容器 的 自 定 义 准备 状况 检查 ， 如 果 
Readiness Probe 检 查 失 败 ，Kubernetes 将 会 把 Pod 从 服务 代理 的 分 发 后 端 
移 除 ， 即 不 会 分 发 请 求 给 该 Pod。 


Probe 文 持 以 下 三 种 检查 方法 。 


。 ExecAction 


说 明 


在 容器 中 执行 指定 的 命令 进行 检查 ， 当 命令 执行 成 功 ( 返 回 码 为 
0) ， 检 查 成 功 。 


配置 参数 
command: 检查 的 命令 ， 字 符 串 数组 。 
示例 


exec: 
command: 
- cat 


- /tmp/health 


。 TCPSocketAction 


说 明 


对 于 容器 中 的 指定 ITCP 端 口 进行 检查 ， 当 TCP 端 口 被 占用 ， 检 碍 成 
功 。 


配置 参数 
port: 检查 的 TCP 端 口 
示例 


tcpSocket : 
port: 8080 


。 HTTPGetAction 


说 明 

发 生 一 个 HTTP 请 求 ， 当 返回 码 介 于 200~400 之 间 时 ， 检 查 成 功 。 
配置 参数 

path: 请 求 的 URI 路 径 ， 可 选项 。 

port: 请 求 的 端口 ， 必 选项 。 

host: 请 求 的 卫 ， 可 选项 ， 默 认 是 Pod 的 PodIP。 


scheme: 请 求 的 协议 ， 可 选项 ， 默 认 是 HTTP。 


示例 


httpGet: 
path: /healthz 


port: 8080 


4.7.1 ”Pod 的 健康 检查 


定义 一 个 Pod， 使 用 Liveness Probe 通过 ExecAction 方 式 检 查 容器 的 
健康 状态 ，Pod 的 定义 文件 liveness-exec-pod.yaml: 


apiVersion: v1 
kind: Pod 
metadata: 
name: liveness-exec-pod 
labels: 
test: liveness 
spec: 
containers: 
- name: liveness 
image: "ubuntu:14.04" 
command: 
- /bin/sh 
- -C 
- echo ok > /tmp/health; sleep 60; rm -rf /tmp/health; sleep 


livenessProbe: 


exec: 

command: 

- cat 

- /tmp/health 
initialDelaySeconds: 15 


timeoutSeconds: 1 


通过 定义 文件 创建 Pod: 


$ kubectl create -f liveness-exec-pod.yaml 


pod "liveness-exec-pod" created 


Pod 创 建 之 初 运行 正常 : 
$ kubectl get pod liveness-exec-pod 
NAME READY STATUS RESTARTS AGE 


liveness-exec-pod 1/1 Running 0 15s 
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过 1 分 钟 以 后 可 以 看 到 Pod 发 生 了 重启 : 


$ kubectl get pod liveness-exec 
NAME READY STATUS RESTARTS AGE 


liveness-exec-pod 1/1 Running 1 1m 





通过 查询 Pod 事 件 可 以 看 到 ，Liveness Probe 检 查 失 败 : 


$ kubectl describe pod liveness-exec-pod|grep Unhealthy 


. Unhealthy Liveness probe failed: cat: /tmp/health: No such fil 


4.7.2 ”Pod 的 准备 状况 检查 


定义 一 个 Pod， 使 用 Readiness Probe 通 过 ExecAction 方 式 检 查 容 器 的 
准备 状况 ，Pod 的 定义 文件 readiness-exec-pod.yaml: 


apiVersion: v1 
kind: Pod 
metadata: 
labels: 
test: readiness 
name: readiness-exec-pod 
spec: 
containers: 
- name: readiness 
image: "ubuntu:14.04" 
command: 
- /bin/sh 
- -C 
- echo ok > /tmp/ready; sleep 60; rm -rf /tmp/ready; sleep 60 
readinessProbe: 
exec: 
command: 
- cat 
- /tmp/ready 
initialDelaySeconds: 15 


timeoutSeconds: 1 


通过 定义 文件 创建 Pod: 


$ kubectl create -f readiness-exec-pod.yaml 


pod "readiness-exec-pod" created 


Pod 2-2 PiS4T IE, AAs MERA: 


$ kubectl get pod readiness-exec 
NAME READY STATUS RESTARTS AGE 


readiness-exec-pod 1/1 Running 0 26S 


过 1 分 钟 以 后 ， 发 现 Pod 的 READY 数 目 变 为 0: 


$ kubectl get pod readiness-exec -pod 
NAME READY STATUS RESTARTS AGE 


readiness-exec- pod 0/1 Running 0 1m 





通过 查询 Pod 事 件 可 以 看 到 ，Readiness Probe 检 查 失 败 : 


$ kubectl describe pod readiness-exec|grep Unhealthy 


. Unhealthy Readiness probe failed: cat: /tmp/ready: No such fil 


4.8 Pod 


Pod 的 调度 指 的 是 Pod 在 创建 之 后 分 配 到 哪 一 个 Node 上 ， 调 度 算 法 
分 为 两 个 步骤 ， 第 一 步 科 选 出 符合 条 件 的 Node， 第 二 步 选择 最 优 的 
Node。 


对 于 所 有 Node， 首 先 Kubernetes 通 过 一 系列 过 滤 函 数 ， 去 除 不 符合 


条 件 的 Node， 当 前 版 本 (Kubernetes v1.1.1) 支持 的 过 滤 函 数 如 下 所 
示 。 


。 NoDiskConflict: 检查 Pod 请 求 的 数据 卷 是 否 与 Node 上 已 存 在 Pod 
挂 载 的 数据 卷 存 在 种 突 ， 如 果 存 在 冲突 ， 则 过 滤 掉 该 Node。 


e PodFitsResources: 检查 Node 的 可 用 资源 〈CPU 和 内 存 ) 是 否 满足 
Pod 的 资源 请 求 。 


。 PodFitsPorts: 检查 Pod 设 置 的 HostPorts 在 Node 上 是 否 已 经 被 其 他 
Pod 占 用 。 


。 ”PodFitsHost: 如 果 Pod 设 置 了 NodeName 属 性 ， 则 算 选 出 指定 的 
Node。 


e PodSelectorMatches: 如 果 Pod 设 置 了 NodeSelector 属 性 ， 则 算 选 出 


e CheckNodeLabelPresence: 检查 Node 是 否 存在 Kubernetes Scheduler 
配置 的 标签 


旬 选 出 符合 条 件 的 Node 来 运行 Pod， 如 果 存 在 多 个 符合 条 件 的 
Node， 那 么 需要 选择 出 最 优 的 Node。Kubernetes 中 通过 一 系列 优先 级 函 
4 (Priority Function) 来 评估 出 最 优 Node。 对 于 每 个 Node， 优 先 级 函数 
给 出 一 个 分 数 : 0~10 CORA EL, OX ANA) ， 而 每 个 优先 级 函数 
设置 有 权重 值 ，Node 的 最 终 分 数 就 是 每 个 优先 级 函数 给 出 的 分 数 进行 加 
权 的 和 ， 比 如 有 两 个 优先 级 函数 priorityFunc1 和 priorityFunc2， 它 们 的 权 
重 值 分 别 是 weight1 和 weight2， 那 么 对 于 NodeA 的 最 终 分 数 是 : 





finalScoreNodeA = (weight1 * priorityFunc1) + (weight2 * priority 





这 样 一 来 ， 通 过 最 终 分 数 对 Node 进 行 排序 ， 得 分 最 高 的 Node 即 最 
优 Node。 如 果 存 在 多 个 Node 并 列 第 一 ， 则 随机 选择 一 个 Node。 





当前 版 本 (Kubernetes v1.1.1) 的 Kubernetes 提 供 的 优先 级 函数 有 如 
下 ; 


。LeastRequestedPriority: 优先 选择 有 最 多 可 用 资源 的 Node。 

e CalculateNodeLabelPriority: 优先 选择 含有 指定 Label 的 Node。 
。BalancedResourceAllocation: 优先 选择 资源 使 用 均衡 的 Node。 
如 何 进行 Node 选 择 呢 ? 


在 一 些 场景 下 希望 Pod 调 度 到 指定 的 Node 上 ， 比 如 有 的 Node 专 门 用 
于 测试 ，Pod 在 正式 上 线 前 ， 需 要 先 在 测试 的 Node 上 运行 ， 测 试 完成 再 
发 布 到 生产 环境 的 Node 上 运行 。 这 时 候 就 可 以 用 到 Node Selector， 通 过 
Node 的 Label 进 行 选择 。 





查询 所 有 的 Node: 
$ kubectl get node 
NAME LABELS STATU 
kube-node-1 kubernetes.io/hostname=kube -node-1 Ready 8d 
kube-node-2 kubernetes.io/hostname=kube -node-2 Ready 8d 
kube-node-3 kubernetes.io/hostname=kube -node-3 Ready 8d 


目前 共有 3 个 Node， 状 态 都 是 Ready， 并 且 有 一 个 默认 的 Label 
kubernetes.io/hostname， 然 后 为 Node kube-node-1 增 加 新 的 Label: 


$ kubectl label nodes kube-node-1 env=test 


node "kube-node-1" labeled 


在 定义 Pod 的 时 候 通 过 设置 Node Selector (.spec.nodeSelector) 来 选 
择 Node，Pod 的 定义 文件 nginx-pod.yaml: 


apiVersion: v1 
kind: Pod 
metadata: 

name: nginx 

labels: 
env: test 

spec: 
containers: 

- name: nginx 
image: nginx 
imagePullPolicy: IfNotPresent 

nodeSelector: 


env: test 


Pod 创 建成 功 后 将 会 被 分 配 到 Node kube-node-1: 


$ kubectl get pod nginx -o wide 


NAME READY STATUS RESTARTS AGE NODE 
nginx 1/1 Running 0 9s kube-node-1 
除了 设置 Node Selector 之 外 ，Pod 还 可 以 通过 Node 


Name (.spec.nodeName) 直接 指定 Node: 


apiVersion: v1 
kind: Pod 
metadata: 
name: nginx 
labels: 
env: test 
spec: 
containers: 
- name: nginx 
image: nginx 
imagePullPolicy: IfNotPresent 


nodeName: kube-node-1 


不 过 还 是 建议 使 用 Node Selector， 因 为 通过 Label 进 行 选择 是 一 种 弱 
绑 定 ， 而 直接 指定 Node Name 是 强 绑 定 ，Node 失 效 时 会 导致 Pod 无 法 调 
度 。 


4.9 问题 定位 指南 


Pod 是 应 用 的 承载 体 ， 当 Pod 运 行 寞 党 的 时 候 ， 可 能 是 Kubernetes 系 
统 问题 ， 也 可 能 是 应 用 本 里 的 问题 ， 那 么 就 需要 提供 足够 的 信息 用 于 问 
题 定 位 ，Kubernetes 针 对 Pod 提 供 的 事件 记录 、 日 志 碍 询 和 远程 调试 功能 
进行 问题 定位 。 





4.9.1 事件 查询 


Kubernetes 从 Pod 的 创建 开始 ， 在 Pod 的 生命 周期 内 会 产生 各 种 事件 
言 上 息 ， 比 如 Pod 完 成 调度 、 下 载 镜 像 完 成 等 。 在 Pod 运 行 异常 的 时 候 ， 通 
过 排除 相关 事件 可 以 了 解 是 否 是 由 于 Kubernetes 的 原因 导致 Pod 异 常 。 














事件 碍 询 可 以 先 碍 询 所 有 的 事件 : 


$ kubectl get event 


然后 再 查询 Pod 相 关 的 事件 : 


$ kubectl describe pod my-pod 


49.2 日志 查询 








日 志 是 一 项 很 重要 的 信息 ， 可 以 用 来 定位 问题 和 显示 应 用 运行 状 
态 。Docker 容 器 可 以 使 用 docker ”logs 命 令 查 询 日 志 ， 可 以 通过 kubectl 
logs 命 令 查 询 Pod 中 容器 的 日 志 。 


现在 要 定义 一 个 Pod， 包 含 两 个 容器 ， 容 器 container1 输 出 一 条 日 志 
然后 正常 退出 (exit 0) ， 容 器 container2 输 出 一 条 日 志 异 常 退 出 (exit 
1) ， 并 且 设 置 Pod 的 重启 策略 是 OnFailure， 即 当 容 器 异常 退出 时 才 进 行 
重启 ，Pod 的 定义 文件 log-pod.yaml: 








apiVersion: v1 
kind: Pod 
metadata: 

name: log-pod 


spec: 


containers : 
- name: container1t 

image: ubuntu:14.04 

command: 

- "bash" 

= Togn 

- "echo \"containeri: ‘date --rfc-3339 ns \"; exit 0" 
- name: container2 

image: ubuntu:14.04 

command: 

- "bash" 

à Tag 

- "echo \"container2: ‘date --rfc-3339 ns \"; exit 1" 


restartPolicy: OnFailure 


通过 定义 文件 创建 Pod: 


$ kubectl create -f log-pod.yaml 


pod "log-pod" created 


Pod 创 建成 功 后 ， 会 重新 创建 异常 退出 的 容器 container2: 


$ kubectl get pod log-pod 
NAME READY STATUS RESTARTS AGE 
log-pod 0/2 Error 1 19s 


DR a 3} al) va Pod F PY 4S 4 a H aS: 


$ kubectl logs log-pod container1 


container1: 2015-11-21 14:52:55.622701243+00:00 


$ kubectl logs log-pod container2 


Pod "log-pod" in namespace "default": container "container2" is 1 
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态 ， 从 而 查询 不 到 当前 运行 日 志 。 但 是 kubectl ”logs 可 以 查询 之 前 容器 
《如 果 存 在 的 话 ) 的 日 志 ， 这 对 于 问题 定位 非常 有 帮助 ， 往 往 容器 停止 
前 的 日 志 价 值 更 高 ， 获 取 方 法 只 需要 加 上 --previous/-p 参 数 : 








$ kubectl logs log-pod container2 -previous 


container2: 2015-11-21 14:53:37.377629086+00: 00 


4.9.3 Pod 的 I 临 终 遗 言 





前 面 我 们 提 到 过 容器 停止 前 的 日 志 价 值 更 高 ， 能 够 获取 最 后 的 错误 
异常 消息 、 调 用 栈 等 ， 我 们 可 以 把 这 些 信 息 形 象 地 称 为 临终 直言 ， 临 终 
遗言 对 于 问题 定位 是 很 有 帮助 的 。 在 Kubernetes 中 为 Pod 提 供 了 一 个 持久 
化 文件 ， 用 来 保存 临终 遗言 。 





Pod 的 定义 中 通过 .spec.containers[].terminationMessagePath 指 定 在 容 
器 中 的 临终 遗言 日 志文 件 的 路 径 ， 默 认 值 是 /devwtermination-log。 这 个 
文件 在 Pod 的 整个 生命 周期 内 都 会 保存 ， 每 次 新 建 一 个 Pod， 都 会 在 宿主 
机 上 创建 一 个 文件 ， 然 后 挂 载 到 Pod 的 容器 中 ， 这 些 文件 不 会 因为 容器 
的 销毁 而 丢失 ， 所 以 容器 可 以 把 临终 遗言 号 入 这 个 文件 ， 方 便 问 题 排 


错 。 


现在 创建 一 个 Pod， 其 中 的 容器 将 写 入 临终 遗言 ，Pod 的 定义 文件 w- 


message-pod.yam!l: 


apiVersion: v1 
kind: Pod 
metadata: 
name: w-message-pod 
spec: 
containers: 
- name: messager 
image: "ubuntu:14.04" 
terminationMessagePath: /dev/termination-log 
command: 
- "bash" 
= bee" 


- "echo \" date --rfc-3339 ns I was going to die\" >> /dev/t 
通过 定义 文件 创建 Pod: 
$ kubectl create -f w-message-pod.yaml 


pod "w-message-pod" created 


$ kubectl get pod w-message-pod 
NAME READY STATUS RESTARTS AGE 


w-message-pod 0/1 Running 2 3m 


Pod 运 行 后 ， 容 器 将 往 文 件 /dewtermination-log 写 入 临终 遗言 ， 然 后 
可 以 进行 查询 : 


$ kubectl get pod w-message-pod \ 
--template="{{range .status.containerStatuses}}{{.lastState.termi 


2015-11-21 15:11:57.457833141+00:00 I was going to die 


4.9.4 远程 连接 容器 





问题 定位 时 往往 需要 连接 到 应 用 的 运行 环境 进行 操作 ， 相 比 于 传统 
的 SSH 方 式 ，Docker 提 供 了 docker attach 和 docker exec 两 个 命令 可 以 连接 
容器 进行 操作 。 同 样 的 ，Kubernetes 对 应 地 提供 了 kubectl attach 和 kubectl 
exec 两 个 命令 用 来 远程 连接 Pod 中 的 容器 。 


其 中 attach 命 令 使 用 起 来 不 太 方便 ， 相 比 之 下 ，exec 命 令 
大 ， 我 们 可 以 使 用 kubectl exec 命 令 远 程 连接 Pod 中 的 容 右 运行 命令 〈 当 
Pod 只 有 一 个 容器 时 ， 不 需要 指定 容器 ): 


$ kubectl exec my-pod -- date 
Wed Jan 6 18:19:07 CST 2016 


或 者 直接 进入 Pod 的 容器 中 : 


$ kubectl exec -ti my-pod /bin/bash 
[root@ my-pod /]# 


提示 


kubectl exec 命 令 需 要 在 Kubemetes Node 上 安装 nsenter。 





第 5 重 
Replication Controller 


Replication ”Controller 是 Kubernetes 中 的 男 一 个 核心 概念 ， 应 用 托管 
在 Kubernetes 之 后 ，Kubernetes 需 要 保证 应 用 有 oe 卖 运 行 ， 这 是 
Replication ”Controller 的 工作 内 容 ， 它 会 确保 任何 时 候 Kubernetes 中 有 指 
定数 量 的 Pod 副 本 (或 者 称 为 实例 ) 。 在 此 基础 上 ，Replication 
Controller 进 一 步 提 供 了 高 级 特性 ， 比 如 弹性 伸缩 、 滚 动 升 级 等 。 本 章 将 
详细 介绍 Replication Controller， 其 中 也 会 涉及 一 些 相 关 的 内 容 。 


5.1 持续 运行 的 Pod 


Kubernetes 提 供 Replication Controller 来 管理 Pod，Replication 
Controller 确 保 任 何 时 候 Kubernetes 集 群 中 有 指定 数量 的 Pod 副 本 在 运 
行 。 如 果 少 于 指定 数量 的 Pod 副 本 ，Replication ”Controller 会 启动 新 的 
Pod， 反 之 会 杀 死 多 余 的 以 保证 数量 不 变 。 我 们 通过 Replication 
Controller 来 创建 持续 运行 的 Pod，Replication “ “Controller 的 定义 文件 my- 
nginx-rc.yaml 如 下 所 示 : 


apiVersion: v1 
kind: ReplicationController 
metadata: 

name: my-nginx 


spec: 


replicas: 2 
selector: 
app: nginx 
template: 
metadata: 
labels: 
app: nginx 
spec: 
containers: 
- name: nginx 
image: nginx 
ports: 


- containerPort: 80 


定义 文件 中 描述 了 Replication Controller 的 属性 和 行为 ， 其 中 的 主要 
要 素 如 下 所 示 。。apiVersion: 声明 Kubernetes 的 API 版 本 ， 目 前 是 v1。 





ekind: 声明 API 对 象 的 类 型 ， 这 里 的 类 型 是 Replication Controller. 
e metadata: 设置 Replication Controller 的 元 数据 。 


e name: 指定 Replication ”Controller 的 名 称 ， 名 称 必须 在 
Namespace 内 唯一 。 


。spec: 配置 Replication Controller 的 具体 规格 。 


e replicas: 设置 Replication Controller 控 制 的 Pod 的 副本 数目 。 
e selector: 指定 Replication Controller 的 Label Selector 来 匹配 Pod 
的 Label。 


e template: 设置 Pod 模 板 ， 同 Pod 的 定义 一 致 。 
通过 定义 文件 创建 Replication Controller: 


$ kubectl create -f my-nginx-rc.yaml 


replicationcontroller "my-nginx" created 


查询 Replication Controller: 


$ kubectl get replicationcontroller my-nginx 
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS AGE 


my -nginx nginx nginx app=nginx 2 





同时 可 以 查询 到 Replication Controller 创 建 的 Pod: 


$ kubectl get pod --selector app=nginx --label-columns app 


NAME READY STATUS RESTARTS AGE APP 
my-nginx-141rs 1/1 Running 0 42s nginx 
my -nginx-cz2gd 1/1 Running 0 42s nginx 


为 Replication ”Controller 设 置 Pod 的 副本 数目 (.spec.replicas) 为 
2， 上 所 以 创建 出 两 个 pod， 并 且 可 以 看 出 Pod 的 名 称 前 组 是 Replication 
Controller 的 名 称 ， 后 级 则 是 5 位 随机 字符 串 。 


现在 删除 一 个 Pod: 


$ kubectl delete pod my-nginx-141Lrs 


pod "my-nginx-141rs" deleted 


马上 可 以 看 到 一 个 新 的 Pod 被 创建 : 


$ kubectl get pod --selector app=nginx 


NAME READY STATUS RESTARTS AGE 
my -nginx-cz2gd 1/1 Running 0 2m 
my-nginx-vc43t 1/1 Running 0 29S 


最 后 删除 Replication Controller: 


$ kubectl delete rc my-nginx 


replicationcontroller "my-nginx" deleted 


相应 的 Pod 也 会 被 删除 : 


$ kubectl get pods --selector app=nginx 


NAME READY STATUS RESTARTS AGE 


使 用 kubect delete 命令 删除 Replication ”Controller， 默 认 会 删除 
Replication Controller 关 联 的 所 有 Pod 副 本 。 如 果 需 要 保留 Pod 运 行 ， 删 除 
Replication Controller 的 时 候 可 以 设置 参数 --cascade=false。 


除了 kubectl create 命令 之 外 ， 也 可 以 通过 kubectl run 命令 创建 
Replication Controller， 下 面 的 命令 将 创建 名 称 为 my-nginx 的 Replication 
Controller， 创 建成 功 返 回 Replication Controller 的 信息 : 


$ kubectl run my-nginx --image nginx --replicas 2 --labels app=ng 


replicationcontroller "my-nginx" created 


5.2 Pod 模 板 


在 实际 操作 中 ， 相 比 于 直接 创建 Pod， 一 般 都 是 在 Replication 
Controller 中 预先 定义 Pod 模 板 ， 通 过 Replication Controller 来 创建 Pod。 


Pod 模 板 是 在 Replication ”Controller 的 定义 中 通过 .spec.template 设 置 
的 。Pod 模 板 的 定义 方法 和 Pod 的 定义 一 致 ， 但 是 有 一 些 需要 注意 的 内 


a 


容 。 





。 在 Pod 模 板 中 不 需要 指定 Pod 的 名 称 ， 如 果 指 定 了 ， 不 会 报错 但 是 
不 起 作用 。 因 为 通过 Pod 模 板 创 建 Pod 的 时 候 会 设置 Pod 
的 a enn 然后 Pod 的 名 称 E metadata.generateName 
拼接 上 5 位 随机 码 ， 这 样 做 的 目的 是 为 了 通过 Pod 模 板 创建 出 来 的 Pod 的 
名 称 是 唯一 的 。 











。Pod 模 板 中 的 重启 策略 必须 是 Always， 因 为 Replication oe 
保证 Pod 持 续 运 行 ， 必 须要 求 Pod 总 是 重启 容器 ， 不 然 谈 何 持续 运 





。Pod 模 板 中 的 Label 不 能 为 空 ， 否 则 Replication Controller 无 法 同 Pod 
模板 创建 出 来 的 Pod 进 行 关 联 。 


下 面 是 一 个 Pod 模 板 示 例 : 


template: 
metadata: 
labels: 
app: nginx 
spec: 
containers: 
- name: nginx 


image: nginx 


ports: 


- containerPort: 80 


Replication Controller 使 用 Pod 模 板 创 建 Pod， 一 旦 创建 成 功 ，Pod 模 





板 和 创建 的 Pod 就 没有 关系 了 。 可 以 修改 Pod 模 板 但 不 会 对 已 创建 的 Pod 
有 任何 影响 ， 也 可 以 直接 更 新 通过 Replication Controller 创 建 的 Pod。 





通过 定义 文件 创建 PodTemplate: 


$ kubectl create -f podtemplate.yaml 


podtemplate "nginx" created 


$ kubectl get podTemplate nginx 
TEMPLATE CONTAINER(S) IMAGE(S) PODLABELS 


nginx nginx nginx name=nginx 


另外 ， 在 Replication ”Controller 定 义 中 可 通过 .spec.templateRef 引 用 
PodTemplate (这 部 分 暂 未 实现) : 


apiVersion: v1 
kind: ReplicationController 
metadata: 
name: my-nginx 
spec: 
replicas: 2 
templateRef: 


name: nginx 


5.3 Replication Controller 和 了 Pod 的 关 
联 


Replication Controller 和 Pod 的 关联 惑 是 通过 Label 实 现 的 ，Label 机 制 
是 Kubernetes 中 很 重要 的 一 个 设计 ， 通 过 Label 进 行 对 象 的 弱 关 联 ， 可 以 
灵活 地 进行 分 类 和 选择 。 就 像 在 社交 网 络 上 ， 对 每 个 人 打上 不 同 的 标 


只 业 、 年 龄 、 兴 趣 爱 好 等 ， 然 后 系统 可 以 根据 标签 推送 不 同 的 业 
务 以 提供 灵活 的 定制 服务 。 


对 于 Pod， ee ，Label 是 一 系列 的 Key/Value 
对 ，Pod《〈 或 者 Pod 模 板 ) 的 定义 中 通过 .metadata.labels 设 置 : 


labels: 
key1: value1 


key2: value2 





Label 的 定义 是 任意 的 ， 但 是 Label 必 须 具 有 可 标识 性 ， 比 如 设置 Pod 
的 应 用 名 称 和 版 本 号 等 。 另 外 ，Label 是 不 具有 唯一 性 的 ， 为 了 更 准确 
地 标识 Pod， 建 议 为 Pod 设 置 不 同 维度 的 Label， 比 如 : 





e "release" : "stable", "release" : "Canary" 


"H W 了 


e "environment" : "dev","environment" qa", "environment" 


"production" 
e "tier" : "frontend","tier" : "backend", "tier" : "cache" 
e "partition" : "customerA","partition"” : "customerB" 
e "track" : "daily","track" : "weekly" 


对 于 Replication Controller 来 说 就 是 通过 Label Selector 来 匹配 Pod 的 
Label， 从 而 实现 关联 关系 。 在 Replication Controller 的 定义 中 通 
过 .spec.selector 来 设置 Label Selector，Replication Controller 的 定义 文件 


my-web-rc.yaml: 


apiVersion: v1 
kind: ReplicationController 
metadata: 
name: my-web 
spec: 
selector: 
app: my-web 
template: 
metadata: 
labels: 
app: my-web 
version: v1 
spec: 
containers: 
- name: my-web 
image: my-web:v1 
ports: 


- containerPort: 80 


通过 定义 文件 创建 Replication Controller: 


$ kubectl create -f my-web-rc.yaml 


replicationcontroller "my-web" created 


$ kubectl get replicationcontroller my-web 


CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR 


my -web my -web my -web: vi app=my -web 


REPLICAS 
1 


通过 Label 查 询 Replication Controller 创 建 出 来 的 Pod: 


$ kubectl get pod --selector app=my-web --label-columns=app 
NAME READY STATUS RESTARTS AGE APP 


my -web-itaxw 1/1 Running 0 27S my -web 


可 将 该 Pod 的 Label app=my-web 修 改 掉 : 


$ kubectl label pod my-web-itaxw app=debug --overwrite 


pod "my-web-itaxw" labeled 


通过 查询 可 以 看 到 马上 有 新 的 Pod 被 创建 出 来 ， 因 为 Replication 
Controller 正 是 通过 Label 关 联 Pod，Pod 的 Label 被 修改 掉 ， 对 Replication 
Controller 而 言 相当 于 减少 一 个 关联 的 Pod， 自 然 束 会 创建 新 的 Pod。 





$ kubectl get pod --selector app --label-columns=app 


NAME READY STATUS RESTARTS AGE APP 
my -web-itaxw 1/1 Running 0 1m debug 
my-web-p411n 1/1 Running 0 16s my -web 


对 于 修改 标签 的 Pod 来 说 ， 相 当 于 脱离 Replication ”Controller 的 控 
制 ， 这 种 方法 适合 对 应 用 进行 调试 〈 或 者 数据 备份 ) ， 相 当 于 有 一 个 脱 
离 控制 的 Pod 可 以 进行 调试 ， 最 后 可 以 删除 这 个 Pod: 


$ kubectl delete pod my-web-itaxw 


pod "my-web-itaxw" deleted 


$ kubectl get pod --selector app --label-columns=app 
NAME READY STATUS RESTARTS AGE APP 


my -web-p411n 1/1 Running 0 1m my -web 


如 果 试 图 创建 Label 为 app=my-web 的 Pod， 会 发 现 Pod 是 创建 不 出 来 
的 ， 因 为 这 个 Pod 和 Replication Controller 的 Label Selector 匹 配 了 ， 那 么 
Replication Controller 会 删除 这 个 Pod 来 保证 Pod 的 副本 数 不 多 也 不 少 。 所 
以 当 多 个 Replication Controller 的 Label Selector 一 样 且 设置 的 Pod 副 本 不 
一 样 的 时 候 ， 会 产生 冲突 。 


5.4 弹性 伸缩 


弹性 伸缩 是 指 适 应 负载 变化 ， 以 弹性 可 伸 纵 方式 提供 资源 ， 特 别 是 
在 虚拟 化 文 持 下 ， 提 高 资源 的 利用 率 和 用 户 满意 度 ， 较 好 地 解决 了 资源 
利用 率 和 应 用 系统 之 间 的 矛盾 ， 是 云 计算 领域 的 关键 能 力 。 想 象 一 下 现 
实 世 界 ， 比 如 大 型 超市 的 出 口 ， 高 峰 时 期 人 流量 大 的 时 候 ， 适 时 增加 结 
算 柜台 ， 而 当 人 沉 量 少 的 时 候 减 少 结算 柜台 。 











同样 反映 到 Kubernetes 中 ， 可 根据 负载 的 高 低 动 态 调整 Pod 的 副本 
数 ， 目 前 Kubernetes 提 供 了 API 接 口 实现 Pod 的 弹性 伸缩 。 当 然 ，Pod 的 
副本 数 本 来 就 是 通过 Replication ” Controller 进行 控制 ， 所 以 Pod 的 弹性 伸 
缩 就 是 修改 Replication Controller 的 Pod 副 本 数 ， 可 以 通过 kubectl scale 命 


首先 创建 Replication Controller， 设 置 的 Pod 副 本 数 为 1，Replication 
Controller 的 定义 文件 my-nginx-rc.yaml: 


apiVersion: v1 


kind: ReplicationController 


metadata: 
name: my-nginx 
spec: 
replicas: 1 
selector: 
app: nginx 
template: 
metadata: 
labels: 
app: nginx 
spec: 
containers: 

- name: nginx 
image: nginx 
ports: 

- containerPort: 80 


restartPolicy: Never 


通过 定义 文件 创建 Replication Controller: 


$ kubectl create -f my-nginx-rc.yaml 


replicationcontroller "my-nginx" created 


Replication Controller 创 建成 功 后 ， 创 建 出 指定 数目 的 Pod: 


$ kubectl get replicationcontroller my-nginx 
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS 


my -nginx nginx nginx app=nginx 1 


AGE 


$ kubectl get pod --selector app=nginx 
NAME READY STATUS RESTARTS AGE 


my -nginx-sb6my 1/1 Running 0 1m 


扩容 Pod 的 副本 数目 到 3: 


$ kubectl scale replicationcontroller my-nginx --replicas=3 


replicationcontroller "my-nginx" scaled 


$ kubectl get replicationcontroller --selector app=nginx 
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS 


my -nginx nginx nginx app=nginx 3 


$ kubectl get pod --selector app=nginx 


NAME READY STATUS RESTARTS AGE 
my -nginx-2hzis 1/1 Running 0 49s 
my -nginx-7b66n 1/1 Running 0 49s 
my -nginx-sb6my 1/1 Running 0 2m 


缩 容 Pod 的 副本 数 到 1: 


$ kubectl scale replicationcontroller my-nginx --replicas=1 


replicationcontroller "my-nginx" scaled 


$ kubectl get replicationcontroller --selector app=nginx 
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS 


my -nginx nginx nginx app=nginx 1 


AGE 


AGE 


$ kubectl get pod --selector app=nginx 
NAME READY STATUS RESTARTS AGE 


my -nginx-7b66n 1/1 Running 0 1m 


kubectl _ scale 如 果 设 置 --current-replicas 参 数 ， 会 先 检 查 当 前 的 Pod 的 
副本 数 是 否 匹 配 ， 不 匹配 的 话 会 报错 ; 





$ kubectl scale rc my-nginx --current-replicas=2 --replicas=1 


Expected replicas to be 2, was 1 


另外 ， 也 可 以 把 Pod 的 副本 数目 设置 为 0， 即 删 除 Replication 
Controller 关 联 的 所 有 Pod: 


$ kubectl scale replicationcontroller my-nginx --replicas=0 


replicationcontroller "my-nginx" scaled 
$ kubectl get replicationcontroller --selector app=nginx 
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS AGE 


my -nginx nginx nginx app=nginx 0 


$ kubectl get pod --selector app=nginx 


NAME READY STATUS RESTARTS AGE 


5.5 上 自动 伸缩 


通过 Replication Controller 可 以 非常 方便 地 实现 Pod 的 弹性 伸缩 ， 在 





此 基础 上 ， 只 要 有 平台 监控 支持 ， 就 可 以 实现 自动 伸缩 的 功能 ， 即 基于 
Pod 的 资源 使 用 情况 ， 根 据 配 置 的 策略 自动 调整 Pod 的 副本 数 。 





在 Kubernetes 中 通过 Horizontal Pod Anutoscaler 来 实现 Pod 的 自动 伸 
44, Horizontal Pod Autoscaler 同 Replication Controller 是 一 一 对 应 的 ， 


Horizontal Pod Autoscaler 将 定时 从 平台 监控 系统 中 获取 Replication 
Controller 关 联 Pod 的 整体 资源 使 用 情况 。 当 和 集 略 匹配 的 时 候 ， 通 过 
Replication Controller 来 调整 Pod 的 副本 数 ， 实 现 自动 伸缩 。 


提示 


在 当前 版 本 (Kubernetes v1.1.1) 中 ，Horizontal Pod Autoscaler 处 
于 Beta 测 试 阶 段 ， 目 前 策略 只 支持 根据 CPU 的 使 用 情况 进行 关联 ， 并 
且 Kubernetes 需 要 安装 平台 监控 〈 可 参考 2.3.2 节 ) 。 





通过 kubectl run 创 建 Replication Controller， 将 运行 一 个 Nginx Pod: 


$ kubectl run nginx --image=nginx --labels app=nginx --requests c 


replicationcontroller "nginx" created 


$ kubectl get replicationcontroller nginx 
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS AGE 


nginx nginx nginx app=nginx 1 


$ kubectl get pod --selector app=nginx 


NAME READY STATUS RESTARTS AGE 


nginx-dqsvi 1/1 Running 0 1m 


通过 kubectl expose 创 建 Service， 代 理 Nginx Pod， 然 后 就 可 以 通过 
http://10.254.133.192 访 问 Nginx Pod: 


$ kubectl expose replicationcontroller nginx --port=80 


service "nginx" exposed 


$ kubectl get service nginx 
NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELECTOR AG 


nginx 110.254.133.192 <none> 80/TCP app=nginx 5s 


现在 将 创建 Horizontal Pod Autoscaler 来 实现 Nginx Pod 的 弹性 伸缩 ， 
Horizontal Pod Autoscaler 定 义 文 件 nginx-hpa.yaml: 


apiVersion: extensions/vibeta1 
kind: HorizontalPodAutoscaler 
metadata: 
name: nginx 
namespace: default 
spec: 
scaleRef: 
kind: ReplicationController 
name: nginx 
subresource: scale 
minReplicas: 1 


maxReplicas: 10 


cpuUtilization: 


targetPercentage: 50 


在 此 Horizontal Pod ”Autoscaler 中 通过 .spec.scaleRef 指 定 对 应 的 


ReplicationController，.spec.minReplicas 和 .spec.maxReplicas 分 别 设 定 Pod 


伸缩 的 最 小 和 最 大 副本 数 。 另 外 设置 了 自动 伸缩 策略 : 当 所 有 关联 Pod 
的 CPU 平均 使 用 率 超过 50% 的 时 候 进 行 扩容 ， 而 少 于 50% 的 时 候 ， 进 
行 缩 容 。 





现在 通过 定义 文件 创建 Horizontal Pod Autoscaler: 


$ kubectl create -f nginx-hpa.yaml 


horizontalpodautoscaler "nginx" created 


提示 


可 以 通过 kubectl autoscale 创 建 Horizontal Pod Autoscaler: 


$ kubectl autoscale rc nginx --min=1 --max=10 --cpu-percent=50 


replicationcontroller "nginx" autoscaled 





创建 成 功 后 查询 Horizontal Pod Autoscaler: 


$ kubectl get horizontalpodautoscaler nginx 
NAME REFERENCE TARGET CURREN 


nginx ReplicationController/nginx/scale 50% 0% 1 


因为 没有 访问 量 ， 所 以 当前 关联 Pod 的 CPU 平 使 用 率 为 0%， 我 们 可 
以 使 用 工具 增加 访问 量 。 当 访问 量 增加 的 时 候 ， 查 询 Horizontal Pod 
Autoscaler， 观 察 变化 : 


$ kubectl get horizontalpodautoscaler nginx 
NAME REFERENCE TARGET CURREN 


nginx ReplicationController/nginx/scale 50% 60% 1 


当 CPU 平 均 使 用 率 超 过 50% 的 时 候 ， 可 以 发 现 对 应 的 Replication 
Controller 的 Pod 副 本 数 变 为 2， 实 现 了 扩容 。 


$ kubectl get horizontalpodautoscaler nginx 
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS AGE 


nginx nginx nginx app=nginx 2 


当 我 们 停止 访问 ，CPU 平 均 使 用 率 降 到 50% 以 下 ，Replication 
Controller 的 Pod 副 本 数 变 为 1， 即 实现 了 缩 容 。 


$ kubectl get horizontalpodautoscaler nginx 
NAME REFERENCE TARGET CURREN 


nginx ReplicationController/nginx/scale 50% 43% 1 
$ kubectl get replicationcontroller nginx 


CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS AGE 


nginx nginx nginx app=nginx 1 


5.6 RINK 





滩 动 升级 是 一 种 平滑 过 渡 的 升级 方式 ， 通 过 逐步 蔡 换 的 策略 ， 保 证 
整体 系统 的 稳定 ， 在 初始 升级 的 时 候 束 可 以 及 时 发 现 、 调 整 问题 ， 以 保 
证 问题 影响 度 不 会 扩大 。 


在 Kubernetes 中 文 持 滚动 升级 ， 现 在 我 们 通过 一 个 例子 演示 应 用 从 
V1 版 本 深 动 升级 到 V2 版 本 。 首 先 创 建 V1 版 本 的 Replication Controller, 
V1 版 本 的 Replication Controller 的 定义 文件 my-web-v1-rc.yaml: 


apiVersion: v1 
kind: ReplicationController 
metadata: 
name: my-web-v1 
spec: 
selector: 
app: my-web 
version: v1 
template: 
metadata: 
labels: 
app: my-web 
version: v1 
spec: 
containers: 
- name: my-web 
image: my-web:v1 
ports: 


- containerPort: 80 


protocol: TCP 


通过 定义 文件 创建 Replication Controller: 


$ kubectl create -f my-web-vi-rc.yaml 


replicationcontroller "my-web-vi" created 


$ kubectl get replicationcontroller my-web-v1 
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR 


my -web-v1 my -web my -web: vi app=my-web, version=v1 


然后 扩容 Replication Controller 的 Pod 副 本 数目 到 4: 


$ kubectl scale rc my-web-v1 --replicas=4 


replicationcontroller "my-web-vi" scaled 


$ kubectl get pods --selector app=my-web 


NAME READY STATUS RESTARTS AGE 
my -web-v1-3dd6v 1/1 Running 0 9s 
my -web-v1-8893c 1/1 Running 0 57S 
my -web-v1-11611 1/1 Running 0 8s 
my-web-v1-rzjp5 1/1 Running 0 9s 


现在 需要 应 用 从 V1 版 本 升级 到 V2 版 本 ，V2 版 本 的 Replication 
Controller 定义 文件 my-web-v2-rc.yaml: 


apiVersion: v1 
kind: ReplicationController 


metadata: 


name: my-web-v2 
spec: 
selector: 
app: my-web 
version: v2 
template: 
metadata: 

labels: 
app: my-web 
version: v2 

spec: 

containers: 

- name: my-web 
image: my-web:v2 
ports: 

- containerPort: 80 


protocol: TCP 


开始 滚动 升级 : 


$ kubectl rolling-update my-web-v1 -f my-web-v2-rc.yaml --update- 
Created my-web-v2 

Scaling up my-web-v2 from © to 4, scaling down my-web-vi from 4 1 
don't exceed 5 pods) 

Scaling my-web-v2 up to 1 

Scaling my-web-vi down to 3 


Scaling my-web-v2 up to 2 


Scaling my-web-vi down to 2 

Scaling my-web-v2 up to 3 

Scaling my-web-vi down to 1 

Scaling my-web-v2 up to 4 

Scaling my-web-vi down to 0 

Update succeeded. Deleting my-web-v1 


replicationcontroller "my-web-vi" rolling updated to "my-web-v2" 





升级 开始 后 ， 首 先 根据 提供 的 定义 文件 创建 V2 版 本 的 Replication 
Controller， 然 后 每 隔 10s (通过 kubectl rolling-update 的 参数 --update- 
period 设 置 ) 逐步 增加 V2 版 本 的 Replication “ Controller 的 Pod 副 本 数 ， 逐 
步 减少 V1 版 本 的 Replication Controller 的 Pod 副 本 数 。 升 级 完成 后 删除 V1 
版 本 的 Replication Controller， 保 留 V2 版 本 的 Replication Controller， 即 实 
现 深 动 升 级 。 


Updating my-web-vi replicas: 3, my-web-v2 replicas: 
Updating my-web-v1 replicas: 2, my-web-v2 replicas: 


Updating my-web-v1 replicas: 1, my-web-v2 replicas: 


RB ù N FB 


Updating my-web-v1 replicas: 0, my-web-v2 replicas: 


升级 期 间 通 过 碍 询 Pod 可 知 ，V2 版 本 的 Pod 正 在 逐渐 符 换 V1 乒 本 的 
Pod， 当 然 这 是 通过 调整 Replication Controller 的 副本 数目 来 控制 的 ， 下 
面 显 示 的 是 升级 过 程 中 的 一 个 阶段 的 状况 : 


$ kubectl get replicationcontroller --selector app=my -web 
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR 
my -web-v1 my -web my -web: vi app=my-web, version=v1 


my -web-v2 my -web my -web:v2 app=my-web, version=v2 


$ kubectl get pod --selector app=my -web 


NAME READY STATUS RESTARTS AGE 
my -web-v1-3dd6v 1/1 Running 0 1m 
my-web-v1-8893c 1/1 Running 0 2m 
my -web-v2-6cg74 1/1 Running 0 19s 
my -web-v2-b4qaz 1/1 Running 0 45s 


待 升 级 完成 ， 即 V2 版 本 的 Pod 完 全 蔡 换 VI1 版 本 的 Pod， 同 时 V1 版 本 
的 Replication Controller 也 被 V2 版 本 的 Replication Controller 蔡 换 ; 


$ kubectl get replicationcontroller --selector app=my -web 
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR 


my -web-v2 my -web my -web:v2 app=my-web, version=v:z 


$ kubectl get pod --selector app=my-web 


NAME READY STATUS RESTARTS AGE 

my -web -v2-7850k 1/1 Running 0 35s 
my -web-v2-bg8ur 1/1 Running 0 1m 
my-web-v2-qr33c 1/1 Running 0 1m 
my -web-v2-y2es3 1/1 Running 0 57S 


如 果 在 升级 过 程 中 ， 发 生 了 错误 中 途 退 出 的 时 候 ， 可 以 选择 继续 升 
级 。Kubernetes 能 够 智能 地 判断 出 升级 中 断 之 前 的 阶段 ， 然 后 紧 接着 继 
续 执 行 升 级 。 另 外 ， 也 可 以 进行 回 退 ， 命 令 如 下 : 


$ kubectl rolling-update my-web-v1 -f my-web-v2-rc.yaml --update- 


Setting "my-web-vi" replicas to 4 


Continuing update with existing controller my-web-vi. 

Scaling up my-web-v1 from 3 to 4, scaling down my-web-v2 from 2 1 
don't exceed 3 pods) 

Scaling my-web-v2 down to 0 

Scaling my-web-vi up to 4 


Update succeeded. Deleting my-web-v2 


回 退 的 方式 实际 上 就 是 升级 的 逆 操 作 ， 逐 步 增加 V1 版 本 的 
Replication Controller 的 副本 数 ， 逐 步 减 少 V2 版 本 的 Replication Controller 
的 副本 数 。 


5.7 Deployment 


Kubernetes 提 供 了 一 种 更 加 简单 的 更 新 Replication Controller 和 Pod 的 
机 制 ， 叫 作 Deployment。 


提示 


在 当前 版 本 〈Kubernetes v1.1.1) 中 ，Deployment 处 于 beta 测 试 阶 
段 ， 需 要 Kubernetes API Server 的 启动 参数 设置 --runtime- 


config=extensions/vlbetal/deployments=true 开 启 Deployment 文 持 。 





我 们 创建 一 个 Deployment，Deployment 的 定义 文件 my-web-v1- 
deployment.yaml: 


apiVersion: extensions/vibetal 
kind: Deployment 
metadata: 
name: my-web-deployment 
spec: 
replicas: 4 
template: 
metadata: 
labels: 
app: my-web 
spec: 
containers: 
- name: my-web 
image: my-web:v1 
ports: 
- containerPort: 80 


protocol: TCP 


Deployment 的 定义 方法 与 Replication Controller 类 似 ， 包 括 Pod 副 本 
数 和 Pod 副 本 的 设置 ， 这 些 定义 将 会 作用 于 Deployment 创 建 的 Replication 


Controller. 
通过 定义 文件 创建 Deployment: 


$ kubectl create -f my-web-v1-deployment.yaml --validate=false 


deployment "my-web-deployment" created 


创建 成 功 后 可 以 查询 到 Deployment 和 其 创建 的 Replication 


Controller: 


$ kubectl get deployment my-web-deployment 
NAME UPDATEDREPLICAS AGE 


my-web-deployment 0/4 32s 


$ kubectl get replicationcontroller --selector app=my -web 
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR 


deploymentrc-3379117081 my-web my-web:v1 app=my-web, dep: 


Deployment 创 建 出 来 的 Replication Controller 的 名 称 是 deploymentrc- 
3379117081, Replication “Controller 使 用 的 是 Deployment 定 义 中 的 Pod 模 
板 。 


Deployment 给 Replication Controller 添 加 了 一 个 Label 
deployment.kubemetes.io/ podTemplateHash=3379117081， 其 中 Label 的 
Value 是 3379117081， 这 是 由 Pod 模 板 计 算出 的 Hash 值 ，Label 的 Key 是 由 
Deployment 中 的 .spec.uniqueLabelKey 指 定 的 ， 默 认 是 
deployment.kubermnetes.io/podTemplateHash， 如 果 为 空 ， 则 不 添加 这 个 
Label. 


Deployment 中 通过 .spec.replicas 指 定 了 预期 的 Pod 副 本 数 ， 不 过 在 刚 
创建 的 时 候 ， 初 始 值 是 0。 


过 一 段 时 间 后 ，Deployment 将 会 设置 Replication Controller 的 Pod 副 | 
本 数 为 4， 相 应 地 创建 出 了 4 个 Pod: 


$ kubectl get deployment my-web-deployment 
NAME UPDATEDREPLICAS AGE 


my-web-deployment 4/4 


$ kubectl get replicationcontroller --selector app=my -web 


CONTROLLER CONTAINER(S) 
deploymentrc-3379117081 my -web 


IMAGE(S) 


my-web:vi 


SELECTOR 


app=my-web, dep: 


$ kubectl get pods --selector app=my-web --label-columns deployme 


podTemplateHash 

NAME 
deploymentrc-3379117081-5ghmj 
deploymentrc-3379117081-g4a0i 
deploymentrc-3379117081-orckb 


deploymentrc-3379117081-r69kt 


1/1 
1/1 
1/1 
1/1 


READY 


Running 
Running 
Running 


Running 


STATUS RESTART 


0 1 


0 1 
0 1 
0 1 


现在 我 们 需要 更 新 应 用 ， 镜 像 my-web:v1 升 级 到 my-web:v2， 为 此 ， 
新 的 Deployment 定 义 文件 my-web-v2-deployment.yaml 如 下 所 示 : 


apiVersion: extensions/vibetal 
kind: Deployment 
metadata: 
name: my-web-deployment 
spec: 
replicas: 4 
template: 
metadata: 
labels: 


app: my-web 


spec: 
containers: 
- name: my-web 
image: my-web:v2 
ports: 
- containerPort: 80 


protocol: TCP 


使 用 新 的 定义 文件 更 新 Deployment: 


$ kubectl apply -f my-web-v2-deployment.yaml --validate=false 


deployment "my-web-deployment" configured 


更 新 生效 后 ， 可 以 查询 到 Deployment 创 建 了 新 的 Replication 


Controller: 


$ kubectl get replicationcontroller --selector app=my -web 


CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR 
deploymentrc-3379117081  my-web my -web:v1 app=my-web, depl 
deploymentrc-3445177370 my -web my -web:v2 app=my-web, depl 


新 创建 出 的 Replication Controller 名 称 为 deploymentrc-3445177370， 
Label 设 置 为 deployment.kubernetes.io/podTemplateHash=3445177370， 
3445177370 是 由 新 的 Pod 模 板 计 算出 的 Hash 值 ， 新 的 Replication 
Controller 使 用 镜像 my-web:v2， 初 始 的 Pod 副 本 数 为 0。 


‘A P64 Deployment #2 till # IA Replication ”Controller， 实 现 Pod 的 
升级 : 


$ kubectl get replicationcontroller --selector app=my -web 


CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR 
deploymentrc-3379117081 my-web my -web:v1 app=my-web, dey 
deploymentrc-3445177370 my-web my -web:v2 app=my-web, dey 


$ kubectl get pod --selector app=my-web --label-columns deploymen 


podTemplateHash 

NAME READY STATUS RESTAR 
deploymentrc-3445177370-4ej3a 1/1 Running 0 
deploymentrc-3445177370-1327a 1/1 Running 0 
deploymentrc-3445177370-reegh 1/1 Running 0 

deploymentrc -3445177370-zhopb 1/1 Running 0 


默认 情况 下 ，Deployment 采 取 的 是 滚动 升级 方式 ， 同 使 用 kubectl 
rolling-update 是 一 致 的 ， 即 逐步 增加 新 的 Replication Controller 的 副本 
数 ， 逐 步 减 少 旧 的 Replication Controller 的 副本 数 ， 通 过 查询 Deployment 
的 事件 可 以 看 到 具体 变化 情况 : 


$ kubectl describe deployment my-web-deployment 


Scaled up rc deploymentrc-3379117081 to 4 
Scaled up rc deploymentrc-3445177370 to 1 
Scaled down rc deploymentrc-3379117081 to 2 
Scaled up rc deploymentrc-3445177370 to 3 
Scaled down rc deploymentrc-3379117081 to 0 


Scaled up rc deploymentrc-3445177370 to 4 


在 Deployment 中 可 以 配置 升级 的 策略 ， 通 过 .spec.strategy.type 指 定 


升级 类 型 ， 包 括 Recreate 和 RollingUpdate。 


。 Recreate: 直接 升级 ， 即 删除 所 有 旧 的 Pod， 然 后 创建 新 的 Pod， 
当前 版 本 (Kubernetes v1.1.1) 暂 未 实现 。 


“RollingUpdate: 深 动 升级 ， 文 持 参数 配置 ， 如 表 5-1 所 示 。 


表 5-1 RollingUpdate 策 略 参数 


参数 说 明 


允许 的 最 大 失效 Pod 数 
值 ， 可 选 配置 ， 值 可 以 
是 绝对 值 (5) 或 者 是 比 
fill (10%) ， 默 认 值 是 
1。 比 如 maxUnavailable 
是 30%， 升 级 开始 后 ， 
旧 的 Replication 
.spec.strategy.rollingUpdate.maxUnavailable | Controller 可 以 立即 缩 容 
30% 的 Pod， 当 新 的 
Replication Controller 创 | 
Replication Controller 可 
以 进一步 缩 容 ， 整 个 升 








级 过 程 至 少 需要 保证 
70% 的 Pod 可 用 





允许 超过 指定 Pod 数 目的 
最 大 数值 ， 可 选 配置 ， 
值 可 以 是 绝对 值 (5) 或 
者 是 比例 (10%) ， 默 
认 值 是 1。 比 如 maxSurge 
是 30%， 升 级 开始 后 ， 
新 的 Replication 
.Spec.strategy.rollingUpdate.maxSurge Controller 可 以 立即 扩容 


30%， 旧 的 Replication 
Controller 删 除 Pod 之 后 ， 
新 的 Replication 
Controller 可 以 继续 扩 
容 ， 在 整个 过 程 中 ， 新 
日 Pod 的 总 数目 不 可 以 超 
过 指定 数目 的 130% 





5.8 一 次 性 任务 的 Pod 


从 程序 运行 形态 上 来 区 分 ， 我 们 可 以 将 Pod 分 为 两 类 : 长 时 运行 服 
务 和 一 次 性 任务 。 大 部 分 应 用 比如 Nginx、Redis 等 都 是 长 时 运行 服务 ， 
另外 也 存在 一 次 性 任务 的 场景 ， 比 如 执行 冒 烟 测试 、 数 据 计 算 等 。 


Replication Controller 创 建 的 Pod 都 是 长 时 运行 服务 ， 相 应 的 ， 
Kubernetes 提 供 了 另 一 种 机 制 ，Job 来 管理 一 次 性 任务 的 Pod。 


提示 : 


在 当前 版 本 (Kubernetes v1.1.1) 中 ，Job 处 于 Beta 测 试 阶段 。 





我 们 现在 使 用 Job 来 计算 圆周 率 ，Job 的 定义 文件 pi-job.yaml; 


apiVersion: extensions/vibetal 
kind: Job 
metadata: 


name: pi 


spec: 
completions: 1 
parallelism: 1 
selector: 
matchLabels: 
app: pi 
template: 
metadata: 
name: pi 
labels: 
app: pi 
spec: 
containers: 
- name: pi 
image: perl 
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2 


restartPolicy: Never 


Job 同 样 是 通过 .spec.template 配 置 Pod 的 模板 的 ， 因 为 是 一 次 性 任务 
Pod， 所 以 Pod 的 重 局 策略 只 能 是 Never 或 者 OnFailure。 


Job 可 以 控制 一 次 性 任务 Pod 的 完成 次 数 〈.spec.completions) 和 并 发 
执行 数 〈.spec. parallelism) ， 当 Pod 成 功 执行 指定 次 数 后 即 认 为 Job 执 行 


完毕 。 
通过 定义 文件 创建 Job; 


$ kubectl create -f pi-job.yaml 


job "pi" created 


$ kubectl get job 
JOB CONTAINER(S) IMAGE(S) SELECTOR SUCCESSFUL 


pi pi perl app in (pi) O 


Job 创 建成 功 后 ， 将 会 创建 运行 Pod: 


$ kubectl get pod --selector app=pi 
NAME READY STATUS RESTARTS AGE 
pi-8117p 1/1 Running 0 6s 


Pod 是 一 次 性 任务 ， 计 算出 圆周 率 就 终止 ， 我 们 可 以 碍 询 到 Pod 输 出 
的 圆周 率 : 


$ kubectl logs pi-8117p 
3.1415926535897932384626433832 7950288419 7169399375105820974944592 








在 一 次 性 任务 Pod 执 行 完 后 ， 显 示 Job 已 经 成 功 执行 1 次 ， 即 完成 任 
务 : 


$ kubectl get job pi 
JOB CONTAINER(S) IMAGE(S) SELECTOR SUCCESSFUL 


pi pi perl app in (pi) 1 


第 6 章 
Service 


为 了 适应 快速 的 业务 需求 ， 微 服务 架构 已 经 逐渐 成 为 主流 ， 微 服务 
架构 的 应 用 需要 有 非常 好 的 服务 编排 文 持 。Kubernetes 中 的 核心 要 素 
Service 便 提供 了 一 套 简 化 的 服务 代理 和 发 现 机 制 ， 天 然 适 应 微服 务 架 
构 ， 任 何 应 用 都 可 以 非常 轻易 地 运行 在 Kubernetes 中 而 无 顷 对 架构 进行 
改动 。 本 和 章 将 前 述 Service 的 基本 概念 和 功能 细节 ， 最 后 介绍 如 何 将 
Service 发 布 给 外 部 网 络 的 方法 。 





6.1 ”Service 代 理 Pod 


在 Kubernetes 中 ， 在 受到 Replication Controller 文 配 的 时 候 ，Pod 副 本 
是 变化 的 ， 比 如 发 生 迁 移 〈 准 确 说 是 Pod 的 重建 或 者 伸缩 的 时 候 。 这 
对 于 Pod 的 访问 者 来 说 就 是 一 种 人 负担， 访问 者 需要 能 够 发 现 这 些 Pod 副 
本 ， 并 且 感 知 Pod 副 本 的 变化 以 便 及 时 进行 更 新 。 


Kubernetes 中 的 Service 是 一 种 抽象 概念 ， 它 定义 了 一 个 Pod 逻 辑 集合 
以 及 访问 它们 的 策略 ，Service 同 Pod 的 关联 同样 是 居于 Label 来 完成 的 。 
Service 的 目标 是 提供 一 种 桥梁 ， 它 会 为 访问 者 提供 一 个 固定 访问 地 址 ， 
用 于 在 访问 时 重 定向 到 相应 的 后 端 ， 这 使 得 非 Kubernetes 原 后 应 用 程 
序 ， 在 无 须 为 Kubernetes 编 写 特定 代码 的 前 提 下 ， 轻 松 访问 后 端 。 





我 们 现在 定义 一 个 Service 来 代理 Pod， 首 先 创 建 Replication 
Controller，Replication Controller 的 定义 文件 my-nginx-rc.yaml: 


apiVersion: v1 
kind: ReplicationController 
metadata: 
name: my-nginx 
spec: 
replicas: 3 
selector: 
app: nginx 
template: 
metadata: 
labels: 
app: nginx 
spec: 
containers: 
- name: nginx 
image: nginx 
ports: 


- containerPort: 80 


通过 定义 文件 创建 Replication Controller: 


$ kubectl create -f my-nginx-rc.yaml 


replicationcontroller "my-nginx" created 


Replication Controller 创 建 出 3 个 Pod 副 本 : 


$ kubectl get pod --selector app=nginx 


NAME READY STATUS RESTARTS 


AGE 


my -nginx -2ywz1 1/1 Running 0 1m 
my -nginx-arjqt 1/1 Running 0 1m 


my -nginx-tok0x 1/1 Running 0 1m 


然后 创建 Service，Service 的 定义 文件 my-nginx-service.yaml: 


apiVersion: v1 
kind: Service 
metadata: 
name: my-nginx 
spec: 
selector: 
app: nginx 
ports: 
- port: 80 
targetPort: 80 


protocol: TCP 





定义 文件 中 描述 了 Service 的 属性 和 行为 ， 其 中 的 主要 要 素 如 下 所 示 
。apiVersion: 声明 Kubernetes 的 API 版 本 ， 目 前 是 v1。 
e kind: 声明 API 对 象 的 类 型 ， 这 里 类 型 是 Service。 
。metadata: 设置 Service 的 元 数据 。 
e name: 指定 Service 的 名 称 ， 名 称 必 须 在 Namespace 内 唯一 。 


。spec: 配置 Service 的 具体 规格 。 


e selector: 指定 Service 的 Label Selector JL ft Pod) Label. 
。ports: 设置 Service 的 端口 转发 规则 。 


通过 定义 文件 创建 Service: 


$ kubectl create -f my-nginx-service.yaml 


service "my-nginx" created 


提示 


除了 kubectl create 之 外 ， 也 可 以 通过 kubectl expose 创 建 Service: 


$ kubectl expose replicationcontroller my-nginx --name=my-nginx 
port=80 


service "my-nginx" exposed 





创建 成 功 后 可 以 查询 Service: 


$ kubectl get service my-nginx 
NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELECTOR 


my -nginx 10.254.226.117 <none> 80/TCP app=nginx 4 


Service 同 Replication ” Controller 一样 都 是 通过 Label 来 关联 Pod 的 ， 
Service 的 定义 中 指定 了 Label Selector 为 app=nginx， 那 么 就 会 关联 前 面 运 
行 的 3 个 Pod。Service 会 将 关联 到 的 Pod 作 为 Service 分 发 请 求 的 后 端 ， 可 
以 查询 Service: 


$ kubectl describe service my-nginx 

Name: my -nginx 

Namespace: default 

Labels: <none> 

Selector: app=nginx 

Type: ClusterIP 

IP: 10.254.226.117 

Port: <unnamed> 80/TCP 

Endpoints: 10.0.62.68:80, 10.0.62.69:80, 10.0.62.70:80 
Session Affinity: None 


No events. 


可 以 看 到 Service 的 Endpoints 属 性 包含 了 3 个 IP: 10.0.62.68、 
10.0.62.69、10.0.62.70， 实 际 上 这 就 是 Service 关 联 的 3 个 Pod 的 PodIP: 


$ kubectl get pod --selector app=nginx -0 yaml|grep podIP 
podIP: 10.0.62.70 
podIP: 10.0.62.68 
podIP: 10.0.62.69 


我 们 看 到 ，Service 的 IP 属 性 显示 为 10.254.226.117， 实 际 上 这 是 
Kubernetes 分 配给 Service 的 一 个 虚拟 IP。 通 过 访问 Service 的 虚拟 IP， 
Kubernetes 会 转发 请 求 到 后 端 Pod。 另 外 ，S$ervice 的 端口 转发 规则 显示 
Service 的 80/TCP 端 口 (通过 spec.ports[0].port 指 定 ) 转发 到 后 端的 80 端 口 

(通过 spec.ports[0].targetPort 指 定 〉， 比 如 访问 10.254.226.117:80 的 请 求 
会 被 转发 到 后 端 10.0.62.68:80、10.0.62.69:80、10.0.62.70:80: 


$ curl 10.254.226.117:80 


... Thank you for using nginx... 


而 当 Pod 发 生变 化 的 时 候 ，Service 会 及 时 更 新 ， 比 如 将 Pod 的 副本 数 


目 减 少 至 1: 


$ kubectl scale replicationcontroller my-nginx --replicas=1 


replicationcontroller "my-nginx" scaled 


$ kubectl get pod --selector app=nginx 
NAME READY STATUS RESTARTS 


my -nginx-tok0x 1/1 Running 0 


Service 相 应 地 进行 了 更 新 : 


$ kubectl describe service my-nginx 
Name: my -nginx 

Namespace: default 

Labels: <none> 

Selector: app=nginx 

Type: ClusterIP 

IP: 10.254.226.117 

Port: <unnamed> 80/TCP 

Endpoints: 10.0.62.69:80 

Session Affinity: None 


No events. 


AGE 


7m 


这 样 一 来 ，Service 就 可 以 作为 Pod 的 访问 入 口 ， 起 到 代理 服务 器 的 
作用 ， 而 对 于 访问 者 来 说 ， 通 过 Service 进 行 访 问 ， 无 须 直接 感知 Pod。 


6.2 Service 的 虚拟 IP 


Kubernetes 分 配给 Service 一 个 固定 IP， 这 是 一 个 虚拟 IP (也 称 为 
ClusterIP) ， 并 不 是 一 个 真实 存在 的 耻 ， 而 是 由 Kubernetes 虚 拟 出 来 
的 。 虚 拟 耳 的 范围 通过 Kubernetes API Server 的 启动 参数 --service-cluster- 
ip-range=10.254.0.0/16 配 置 ， 查 询 Service: 





$ kubectl get service 


NAME CLUSTER_IP EXTERNAL_IP PORT(S) SEL 
kubernetes 10.254.0.1 <none> 443/TCP <non 
my -nginx 10.254.226.117 <none> 80/TCP app= 


可 以 查询 到 两 个 Service， 其 中 第 一 个 Service 是 由 Kubernetes 默 认 创 
建 的 ， 它 代表 着 Kubernetes API ”Server。 两 个 Service 的 虚拟 IP 都 属于 
10.254.0.0/16 范 围 ， 在 Service 定 义 中 可 以 通过 .spec.clusterIP 指 定 虚拟 
IP， 指 定 的 卫 必 须 在 指定 范围 内 ， 并 且 该 虚拟 了 未 被 分 配 使 用 : 


apiVersion: v1 
kind: Service 
metadata: 
name: my-nginx 
spec: 
selector: 
app: nginx 
ports: 
- name: http 
port: 80 


targetPort: 80 
protocol: TCP 


clusterIP: 10.254.249.161 


如 果 Service 设置 .spec.clusterIP 为 None， 表 示 不 给 Service 分 配 虚 
拟 IP， 我 们 称 为 Headless Service: 


apiVersion: v1 
kind: Service 
metadata: 

name: my-nginx 
spec: 

selector: 


app: nginx 


ports: 
- name: http 
port: 80 


targetPort: 80 
protocol: TCP 


clusterIP: None 


虚拟 IP 属 于 Kubernetes 内 部 的 虚拟 网 络 ， 外 部 是 寻 址 不 到 的 。 在 
Kubernetes 系 统 中 ， 实 际 上 是 由 Kubernetes Proxy 组 件 负 责 实 现 虚 拟 IP 路 
由 和 转发 的 ， 所 以 在 Kubernetes Node 中 我 们 都 运行 了 Kubernetes Proxy, 
从 而 在 容器 履 盖 网 络 之 上 又 实现 了 Kubernetes 层 级 的 虚拟 转 友 网 络 。 


6.3 ”服务 代理 


在 逻辑 层面 上 ，Service 可 以 被 认为 是 真实 应 用 的 抽象 ， 每 一 个 
Service 关 联 着 一 系列 的 Pod。 在 物理 层面 上 ，Service 义 是 真实 应 用 的 代 
理 服务 器 ， 对 外 表现 为 一 个 单一 访问 入 口 ， 通 过 Kubernetes Proxy 转 发 请 
求 到 Service 关 联 的 Pod。 


Service 同 样 是 根据 Label Selector 来 粒 选 Pod 进 行 天 联 的 ， 实 际 上 
Kubernetes 在 Service 和 Pod 之 间 通 过 Endpoints 衔 接 ，Endpoints 同 Service 
关联 的 Pod 相 对 应 ， 可 以 认为 是 Service 的 服务 代理 后 端 ，Kubernetes 会 根 
据 Service 关 联 到 的 Pod 的 PodIP 信 息 组 合成 一 个 Endpoints。 





我 们 现在 创建 一 个 Service， 定 义 文件 my-nginx-service.yaml: 


apiVersion: v1 
kind: Service 
metadata: 

name: my-nginx 
spec: 

selector: 


app: nginx 


ports: 
- name: http 
port: 80 


targetPort: 80 
protocol: TCP 

- name: https 
port: 443 
targetPort: 443 


protocol: TCP 


Service 的 定义 中 设置 了 两 个 端口 转发 规则 。 当 Service 只 配置 一 个 
端口 的 时 候 ， 端 口 的 名 称 是 可 选项 ， 而 当 Service 配 置 多 个 端口 的 时 候 ， 


每 个 端口 的 name 就 是 必 选 项 。 
通过 定义 文件 创建 Service: 


$ kubectl create -f my-nginx-service.yaml 


service "my-nginx" created 


$ kubectl get service my-nginx 
NAME CLUSTER_IP EXTERNAL_IP PORT(S) 
my -nginx 10.254.181.218 <none> 80/TCP, 443/TCP 


Service 将 通过 Label app=nginx 关 联 到 1 个 Pod: 


$ kubectl get pod --selector app=nginx 
NAME READY STATUS RESTARTS AGE 


my -nginx-4s971 1/1 Running 0 48s 


Kubernetes 创 建 Service 的 同时 ， 会 自动 创建 跟 Service 同 名 的 
Endpoints: 


$ kubectl get endpoints my-nginx -0 yaml 
apiVersion: v1 
kind: Endpoints 
metadata: 
creationTimestamp: 2015-11-28T03:35:52Z 
name: my-nginx 


namespace: default 


SEL 


app=n¢ 


resourceVersion: "224471" 
selfLink: /api/vi/namespaces/default/endpoints/my -nginx 
uid: 1ff974f4-9581-11e5-b92e-005056817c3e 
subsets: 
- addresses: 
- ip: 10.0.62.71 
targetRef: 
kind: Pod 
name: my-nginx-4s971 
namespace: default 
resourceVersion: "224453" 


uid: 33e8b6e0-9581-11e5-b92e-005056817c3e 


ports: 
- name: http 
port: 80 


protocol: TCP 
- name: https 
port: 443 


protocol: TCP 


可 以 看 到 Endpoints 包 含 Service 关 联 到 的 Pod 的 PodIP，Service 根 据 端 
口 对 应 Endpoints 的 相应 端口 : 


$ kubectl describe service my-nginx 
Name: my-nginx 
Namespace: default 


Labels: <none> 


Selector: app=nginx 

Type: ClusterIP 

IP: 10.254.181.218 
Port: http 80/TCP 
Endpoints: 10.0.62.71:80 
Port: https 443/TCP 
Endpoints: 10.0.62.71:443 
Session Affinity: None 


No events. 


Service 不 仅 可 以 代理 Pod， 还 可 以 代理 任意 其 他 后 端 ， 比 如 运行 在 
Kubernetes 外 部 的 服务 。 假 设 现在 要 使 用 一 个 Service 代 理 外 部 MySQL 服 
务 ， 不 用 设置 Service 的 Label Selector，Service 的 定义 文件 mysql- 


service.yaml: 


apiVersion: v1 
kind: Service 
metadata: 
name: mysql 
spec: 
ports: 
- port: 3036 
targetPort: 3036 


protocol: TCP 


同时 定义 跟 Service 同 名 的 Endpoints，Endpoints 中 设置 了 MySQL 的 
IP: 192.168.3.180，Endpoints 的 定义 文件 mysql-endpoints.yaml; 


apiVersion: v1 
kind: Endpoints 
metadata: 
name: mysql 
subsets: 
- addresses: 
- ip: 192.168.3.180 
ports: 
- port: 3036 


protocol: TCP 


通过 定义 文件 创建 Service 和 Endpoints: 


$ kubectl create -f mysql-service.yaml -f mysgl-endpoints. yaml 
service "mysql" created 


endpoints "mysql" created 


HY UAW Fl Service} js HRI] K xe XX A Endpoints: 


$ kubectl get endpoints mysql 
NAME ENDPOINTS AGE 
mysql 192.168.3.180: 3036 23S 


$ kubectl describe service mysql 
Name: mysql 

Namespace: default 

Labels: <none> 


Selector: <none> 


Type: ClusterIP 

IP: 10.254.223.0 

Port: <unnamed> 3036/TCP 
Endpoints: 192.168.3.180:3036 
Session Affinity: None 


No events. 


当 Service 的 Endpoints 包 含 多 个 IP 的 时 候 ， 即 服务 代理 存在 多 个 后 
端 ， 将 进行 请 求 的 负载 均衡 ， 默 认 的 负载 均衡 策略 是 轮 询 或 者 随机 《〈 根 
据 Kubernetes Proxy 的 模式 决定 ) 。Service 文 持 基 于 源 了 地 址 的 会 话 保 
持 ， 通 过 .spec.sessionAffinity 设 置 为 ClientIP: 


apiVersion: v1 
kind: Service 
metadata: 

name: my-nginx 
spec: 

selector: 


app: nginx 


ports: 
- name: http 
port: 80 


targetPort: 80 
protocol: TCP 


sessionAffinity: ClientIP 


6.4 ”服务 友 现 


微服 务 染 构 是 一 种 新 流行 的 架构 模式 ， 相 比 于 传统 的 单 块 染 构 模 
式 ， 微 服务 架构 提倡 将 应 用 划分 成 一 组 小 的 服务 。 每 个 服务 运行 在 其 独 
立 的 进程 中 ， 服 务 之 间 互 相 协 调 、 互 相配 合 ， 服 务 与 服务 间 采 用 轻 量 级 
的 通信 机 制 互相 沟通 。 每 个 服务 都 围绕 着 具体 业务 进行 构建 ， 并 且 能 够 
被 独立 部 车 和 运行 。 


可 以 说 Docker 的 轻 量 级 容器 技术 天 然 适 合 微服 务 架 构 ， 每 一 个 微服 
务 都 通过 Docker 进 行 打包 、 部 署 和 运行 。 而 Docker 的 集装箱 能 力 为 微服 
务 架构 保 敬 护航 ， 可 以 快速 、 轻 松 地 实现 每 个 组 件 的 测试 和 升级 ， 将 微 
服务 架构 的 优势 最 大 化 。 


但 是 应 用 的 微服 务 化 也 将 带 来 新 的 挑战 ， 其 中 一 个 束 是 把 应 用 划分 
成 多 个 分 布 式 组 件 运 行 ， 每 个 组 件 义 将 进行 集群 化 扩展 ， 组 件 和 组 件 之 
间 的 相互 发 现 和 通信 将 会 变 得 复杂 起 来 ， 而 一 套 服务 编排 机 制 束 显 得 非 


常 重要 。 











Kubernetes 提 供 了 强大 的 服务 编排 能 力 ， 微 服务 化 应 用 的 每 一 个 组 
件 都 以 Service 进 行 抽象 ， 组 件 和 组 件 之 间 只 需要 访问 Service 即 可 以 互相 
通信 ， 而 无 须 感知 组 件 的 集群 变化 。 同 时 Kubernetes 为 Service 提 供 了 服 
务 发 现 的 能 力 ， 组 件 和 组 件 之 间 可 以 简单 地 互相 发 现 。 





Kubernetes 中 支持 两 种 服务 发 现 方法 : 环境 变量 和 DNS。 
6.4.1 环境 变量 


当 有 Pod 被 创建 的 时 候 ，Kubernetes 将 为 Pod 设 置 每 一 个 Service 的 相 
关 环 境 变 量 ， 这 些 环境 变量 包括 两 种 类 型 。 


e Kubernetes Services} i= 4 = 


Kubernetes 为 Service 设 置 的 环境 变量 形式 ， 包 括 : 


{SVCNAME}_SERVICE_HOST 
{SVCNAME}_SERVICE_PORT 
{SVCNAME}_SERVICE_PORT_{PORTNAME } 


其 中 的 服务 名 和 端口 名 转 为 大 写 ， 连 字符 转换 为 下 夯 线 。 


。Docker Link 环 境 变 量 


相当 于 通过 Docker 的 --link 参 数 实 现 容器 连接 时 设置 的 环境 变量 形 
式 ， 可 参考 https:/docs.docker.comyuserguide/dockerlinks/。 


比如 现在 有 一 个 Service， 查 询 信 息 如 下 : 


$ kubectl describe service my-dns 
Name: my-dns 

Namespace: default 

Labels: <none> 

Selector: run=my-dns 

Type: ClusterIP 

IP: 10.254.105.183 

Port: dns 53/UDP 

Endpoints: 10.0.10.24:53 

Port: dns-tcp 53/TCP 


Endpoints: 10.0.10.24:53 
Session Affinity: None 


No events. 


这 个 Service 对 应 的 环境 变量 如 下 : 


i=! 


# Kubernetes Service 环 境 变 量 





MY_DNS_SERVICE_HOST=10.254.105.183 
MY_DNS_SERVICE_PORT_DNS=53 
MY_DNS_SERVICE_PORT_DNS_TCP=53 





MY_DNS_SERVICE_PORT=53 


# Docker Link 环 境 变量 





MY_DNS_PORT_53_UDP_PORT=53 





MY_DNS_PORT_53_TCP_ADDR=10. 254.105.183 





MY_DNS_PORT=udp://10.254.105.183:53 
MY_DNS_PORT_53_UDP=udp://10.254.105.183:53 








MY_DNS_PORT_53_UDP_PROTO=udp 
MY_DNS_PORT_53_UDP_ADDR=10. 254.105.183 





MY_DNS_PORT_53_TCP_PORT=53 





MY_DNS_PORT_53_TCP=tcp://10.254.105.183:53 





MY_DNS_PORT_53_TCP_PROTO=tcp 











可 以 看 到 ， 环 境 变量 中 记录 了 Service 的 虚拟 IP 以 及 端口 和 协议 信 
四 。 这 样 一 来 ，Pod 中 的 程序 就 可 以 使 用 这 些 环境 变量 发 现 Service。 


环境 变量 服务 发 现 方式 是 Kubernetes 默 认 支持 的 ， 但 是 此 种 方式 存 
在 限制 。 首 先 环 境 变 量 是 租户 隔离 的 ， 即 Pod 只 能 获取 同 Namespace 中 的 








Service 的 环境 变量 。 另 外 ，Pod 和 Service 的 创建 顺序 是 有 要 求 的 ， 即 
Service 必 须 在 Pod 创 建 之 前 被 创建 ， 否 则 Service 环 境 变 量 不 会 设置 到 Pod 
中 。DNS 服 务 发 现 方 式 则 没有 这 些 限 制 。 











6.4.2 DNS 


DNS 服务 发 现 方式 需要 Kubernetes 提 供 Cluster DNSF, Cluster 
DNS 会 监控 Kubernetes API， 为 每 一 个 Service 创 建 DNS 记 录用 于 域名 解 
析 ， 这 样 在 Pod 中 就 可 以 通过 DNS 域 名 获取 Service 的 访问 地 址 。 而 对 于 
一 个 Service，Cluster DNS 会 创建 两 条 DNS 记 录 : 





[service_name].[namespace_name].[cluster_domain ] 


[service_name].[namespace_name].svc.[cluster_domain] 


Cluster DNS 的 安装 方法 可 参考 2.3.1 节 ， 本 书 使 用 的 Cluster DNS 
ServerfJIP910.254.10.2, Cluster DNS 的 本 地 域 为 cluster.local。 


比如 有 一 个 Service 的 名 称 是 my-service，Namespace 是 my-ns， 
Cluster DNS 会 创建 DNS 记 录 : 


my-service.my-ns.cluster.local 


my-service.my-ns.svc.cluster.local 


对 于 如 何 通过 Cluster DNS 进行 Service 的 域名 解析 ， 需 要 了 解 Linux 
的 DNS 域名 解析 机 制 。Linux 系 统 中 的 DNS 域名 解析 是 通 
过 /etc/resolv.conf 进 行 配置 的 ， 它 的 格式 很 简单 ， 每 行 以 一 个 关键 字 开 
头 ， 后 接 配置 参数 。/etc/resolv.conf 中 的 相关 关键 字 说 明 如 表 6-1 所 示 。 


#6-1 /etc/resolv. conf 关 键 字 


关键 字 说 明 
nameserver DNS 服务 器 的 耳 地址， 可 以 有 很 多 行 的 nameserver， 每 一 个 带 一 个 耻 地 址 ， 在 查询 
时 就 按 nameserver 在 本 文件 中 的 顺序 进行 

domain 主机 的 域名 ， 当 为 没有 域名 的 主机 进行 DNS 查询 时 使 用 



























































Search 服务 器 搜索 域 ， 它 的 多 个 参数 指明 域名 查询 顺序 。 当 要 查询 没有 域名 的 主 
二， 主机 将 在 由 search 声 明 的 域 中 分 别 查 找 
options 解析 选项 值 ， 以 Key/Value 对 的 方式 出 现 















































Pod 中 的 容器 使 用 容器 宿主 机 的 DNS 域名 解析 配置 ， 称 为 默认 DNS 
配置 。 另 外 ， 如 采 Kubernetes 部 普 并 设置 了 Cluster DNS 文 持 ， 那 么 在 创 
建 Pod 的 时 候 ， 默 认 会 将 Cluster DNS 的 配置 写 入 Pod 中 容器 的 DNS 域名 
解析 配置 中 ， 称 为 Cluster DNS 配置 。 


比如 ，Kubernetes Node 的 /etc/resolv.conf 配 置 如 下 : 


# Generated by NetworkManager 


nameserver 218.85.157.99 


在 Pod 的 定义 中 通过 .spec.dnsPolicy 设 置 Pod 的 DNS 策略 ， 默 认 值 是 
ClusterFirst， 查 看 DNS 筑 略 设 置 为 ClusterFirst 的 Pod 中 容器 


的 /etc/resolv.conf: 


$ kubectl exec my-app -- cat /etc/resolv.conf 

nameserver 10.254.10.2 

nameserver 218.85.157.99 

search default.svc.cluster.local svc.cluster.local cluster.local 


options ndots:5 


+H nameserver 10.254.10.27¢ Cluster DNS 配置 ，nameserver 
218.85.157.99 是 容器 宿主 机 的 默认 DNS 配置 。 根 据 先后 顺序 ， 会 优先 使 


用 Cluster DNS 进行 域名 解析 。 另 外 ， 配 置 中 包括 根据 Pod 的 Namespace 
和 Cluster Domain 设 置 DNS 服务 器 搜索 域 : 


search [namespace_name].svc.[cluster_domain] svc.[cluster_domain] 


比如 在 Namespace my-ns 下 的 Pod 的 DNS 服务 器 的 搜索 域 ; 


search my-ns.svc.cluster.local svc.cluster.local cluster.local 


因为 设置 了 DNS 服务 器 的 搜索 域 ， 在 Pod 中 就 可 以 使 用 
[service_namel].[Inamespace_name] 访 问 到 任意 Namespace 的 Service， 而 使 
用 [service_name] 可 以 访问 到 同 Namespace 下 的 Service。 比 如 对 于 
Namespace my-ns 下 的 Service my-service， 任 意 Namespace 的 Pod 通 过 my- 
service. my-ns 可 以 解析 发 现 Service: 


$ kubectl exec my-pod -- nslookup my-service.my-ns --namespace=de 
Server: 10.254.10.2 


Address: 10.254.10.2#53 


Name: my-service.my-ns.svc.cluster.local 


Address: 10.254.0.235 


同 Namespace 下 的 Pod 可 以 通过 my-service 解 析 发 现 Service: 


$ kubectl exec my-pod -- nslookup my-service --namespace=my-ns 
Server: 10.254.10.2 


Address: 10.254.10.2#53 


Name: my-service.my-ns.svc.cluster.local 


Address: 10.254.0.235 


Ak, Cluster DNS 会 为 Headless Service 的 域名 添加 其 Endpoints 的 所 
有 IP， 即 可 以 实现 DNS 的 负载 均衡 : 


$ kubectl describe service my-service 

Name: my -service 

Namespace: default 

Labels: <none> 

Selector: app=nginx 

Type: ClusterIP 

IP: None 

Port: <unnamed> 80/TCP 

Endpoints: 10.0.62.19:80, 10.0.62.20:80, 10.0.62.21:80 
Session Affinity: None 


No events. 


$ kubectl exec my-pod -- nslookup my-service 
Server: 10.254.10.2 


Address: 10.254.10.2#53 


Name: my-service.default.svc.cluster.local 
Address: 10.0.62.20 
Name: my-service.default.svc.cluster.local 
Address: 10.0.62.19 
Name: my-service.default.svc.cluster.local 


Address: 10.0.62.21 


6.5 Ti Service 


Service 的 虚拟 IP 是 由 Kubernetes 虚 拟 出 来 的 内 部 网 络 ， 外 部 网 络 是 
无 法 寻 址 到 的 ， 但 是 有 一 些 Service 义 需要 对 外 骏 露 ， 比 如 Web 前 问 。 这 
时 候 就 需要 增加 一 层 网 络 转发 ， 即 外 网 到 内 网 的 转 及 ，Kubernetes 提 供 
了 NodePort Service、LoadBalancer Service 和 Ingress 可 以 发 布 Service。 





6.5.1 NodePort Service 


NodePort Service 是 类 型 为 NodePort 的 Service，Kubernetes 除 了 会 分 
配给 NodePort Service 一 个 内 部 的 虚拟 卫 ， 另 外 会 在 每 一 个 Node 上 录 露 端 
口 NodePort， 外 部 网 络 可 以 通过 [NodeIP]:[NodePort] 访 问 到 Service。 


我 们 现在 创建 一 个 NodePort Service: 


apiVersion: v1 
kind: Service 
metadata: 

name: my-nginx 
spec: 

selector: 


app: nginx 


ports: 
- name: http 
port: 80 


targetPort: 80 


protocol: TCP 


type: NodePort 


创建 成 功 后 查询 NodePort Service: 


$ kubectl describe service my-nginx 
Name: my -nginx 
Namespace: default 
Labels: <none> 
Selector: app=nginx 
Type: NodePort 

IP: 10.254.38.180 
Port: http 80/TCP 
NodePort: http 32143/TCP 
Endpoints: <none> 
Session Affinity: None 


No events. 


可 以 看 到 ，Kubernetes 给 NodePort Service 中 每 一 个 端口 都 创建 了 一 
个 NodePort (http 32143/TCP) ， 在 NodePort ”Service 定 义 中 可 以 通 
过 .spec.ports[].nodePort 指 定 固定 NodePort，NodePort 的 范围 默认 是 
30000~32767， 可 以 通过 Kubernetes API Server 的 启动 参数 --service-node- 
port-range 指 定 范 围 。 


NodePort Service 就 可 以 通过 [NodeIP]:J[NodePort] 访 问 ， 而 当 NodeIP 
是 一 个 公 网 卫 时 ， 外 部 束 可 以 访问 到 NodePort Service Y 。 


6.5.2 LoadBalancer Service 


LoadBalancer Service 是 类 型 为 LoadBalancer 的 Service，LoadBalancer 
Service 是 建立 在 NodePort Service 集 群 上 的 ，Kubernetes 会 分 配给 
LoadBalancer ”Service 一 个 内 部 的 虚拟 IP， 并 且 烘 露 NodePort。 除 此 之 
外 ，Kubernetes 请 求 底 层 云 平台 创建 一 个 负载 均衡 器 ， 将 每 个 Node 作 为 
后 端 ， 负 载 均衡 器 将 转发 请 求 到 [NodelIP]:[NodePort]。 








LoadBalancer ”Service 需 要 底层 云 平台 支持 创建 负载 均衡 器 ， 比 如 
GCE， 现 在 创建 一 个 LoadBalancer Service: 


apiVersion: v1 
kind: Service 
metadata: 

name: my-nginx 
spec: 

selector: 


app: nginx 


ports: 
- name: http 
port: 80 


targetPort: 80 
protocol: TCP 


type: LoadBalancer 


Kubernetes 会 分 配给 LoadBalancer Service 一 个 内 部 的 虚拟 IP， 并 且 
暴露 NodePort。 进 一 步 的 ，Kubernetes 请 求 底 层 云 平 台 创 建 一 个 负载 均 


衡器 ， 作 为 访问 LoadBalancer Service 的 外 部 访问 入 口 。 负 载 均衡 器 由 底 
层 云 平台 创建 提供 ， 会 包含 一 个 LoadBalancerIP， 可 以 认为 是 
LoadBalancer Service 的 外 部 IP， 查 询 LoadBalancer Service: 


$ kubectl get svc my-nginx 
NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELEC 
my-nginx 10.254.147.57 78.110.25.19 80/TCP app=ngi 


其 中 EXTERNAL IP:78.110.25.19 就 是 LoadBalancer ”Service 的 外 部 
IP。 人 负载 均衡 器 将 每 个 Node 作 为 后 端 ， 当 请 求 78.110.25.19:80 时 ， 人 负载 
均衡 器 将 转发 请 求 到 相应 的 [NodeIP]:[NodePort]， 从 而 访问 到 


LoadBalancer Service。 


6.5.3 Ingress 


Kubernetes 提 供 了 一 种 HTTP 方 式 的 路 由 转发 机 制 ， 称 为 Ingress。 
Ingress 的 实现 需要 两 个 组 件 文 持 ，Ingress ”Controller 和 HTTP 代 理 服 务 
器 。HTTP 代 理 服 务 器 将 会 转发 外 部 的 HTTP 请 求 到 Service， 而 Ingress 
Controller 则 需要 监控 Kubernetes API， 实 时 更 新 HTTP 代 理 服务 器 的 转发 
规则 。 





提示 


在 当前 版 本 〈Kubernetes v1.1.1) 中 ，Ingress 处 于 beta 测 试 阶段 。 





我 们 现在 创建 一 个 mgress，Ingress 的 定义 文件 my-ingress.yaml: 


apiVersion: extensions/vibetal 
kind: Ingress 
metadata: 
name: my-ingress 
spec: 
rules: 


- host: my.example.com 


http: 
paths: 
- path: /app 
backend: 


serviceName: my-app 


servicePort: 80 





Ingress ”定义 中 的 .spec.rules ”设置 了 转发 规则 ， 其 中 配置 了 一 条 规 
则 ， 当 HTTP 请 求 的 host 为 my.example.com 且 path 为 /app 时 ， 转 发 到 
Service my-app 的 80 端 口 。 


通过 定义 文件 创建 Ingress: 


$ kubectl create -f my-ingress.yaml 


ingress "my-ingress" created 


创建 成 功 后 可 以 查询 Ingress: 


$ kubectl get ingress my-ingress 


NAME RULE BACKEND ADDRESS 


my-ingress - 
my.example.com 


/app my-app:80 


当 Ingress 创 建成 功 后 ， 需 要 Ingress Controller 根 据 Ingress 的 配置 ， 设 
置 HTTP 代 理 服 务 器 的 转发 策略 ， 外 部 通过 HTTP 代 理 服务 器 就 可 以 访问 


到 Service。 


在 当前 版 本 〈Kubernetes v1.1.1) 中 ，Ingress Controller 和 HTTP 代 理 
服务 器 是 作为 外 部 组 件 运 行 的 。 官 方 提供 了 GCE Load-Balancer 作 为 
HTTP 代 理 服 务 器 ， 男 外 也 可 以 使 用 HAProxy 或 者 Nginx 等 开源 方案 。 


以 Nginx 为 例 ， 将 Nginx 配 置 文件 以 模板 形式 编写 : 


const ( 
nginxConf = ` 
events { 
worker_connections 1024; 
} 
http { 
{{range $ing := .Items}} 
{{range $rule := $ing.Spec.Rules}} 
server { 
listen 80; 
server_name {{$rule.Host}}; 
resolver 127.0.0.1; 
{{ range $path := $rule.HTTP.Paths }} 
location {{$path.Path}} { 


proxy_pass http://{{$path.Backend.ServiceName}}:{{$path.Bac 
t{ {end} } 


s{{end} } {fend} } 
3 
) 
Ingress Controller !ii #Kubernetes API: 
for { 
rateLimiter.Accept() 
ingresses, err := ingClient.List(labels.Everything(), fields 
if err != nil || reflect.DeepEqual(ingresses.Items, known. Ite 
continue 
} 
if w err := os.Create("/etc/nginx/nginx.conf"); err != nil - 
log.Fatalf ("Failed to open %v: %v", nginxConf, err) 
} else if err := tmpl.Execute(w, ingresses); err != nil { 
log.Fatalf("Failed to write template %v", err) 
} 
shellOut("nginx -s reload") 
} 
最 终生 成 的 Nginx 配 置 文件 如 下 : 
events { 
worker_connections 1024; 
} 


http { 


server { 
listen 80; 
server_name my.example.com; 


resolver 127.0.0.1; 


location /app { 


proxy_pass http://my-app:80; 


这 样 一 来 ，Nginx 将 作为 访问 入 口 ， 访 问 http://my.example.com/app 
的 请 求 将 会 转发 到 http://my-app:80， 即 访问 到 Service。 


第 7 章 


PLUS 


BUR AST SAS ae A a» ~%Kubernetes* F 2x dia @ FE it xe 
义 ， 提 供 了 丰富 强大 的 功能 。 本 章 将 数据 卷 按照 功能 划分 为 三 类 : 本 地 
数据 卷 、 网 络 数据 卷 和 信息 数据 卷 ， 并 一 一 进行 说 明 ， 包 括 使 用 方法 、 
配置 参数 和 示例 。 另 外 ， 其 中 结合 示例 详细 介绍 了 Persistent Volume 和 


Persistent Volume Claim. 
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在 Kubernetes 系 统 中 ， 当 Pod 重 建 的 时 候 ， 数 据 是 会 丢失 的 ， 
Kubernetes 也 是 通过 数据 卷 来 提供 Pod 数 据 的 持久 化 的 。Kubermnetes 数 据 
卷 是 对 Docker 数 据 卷 的 扩展 ，Kubernetes 数 据 卷 是 Pod 级 别 的 ， 可 以 用 来 
实现 Pod 中 容器 的 文件 共享 。 





Kubernetes 数 据 卷 适 配 对 接 各 种 存储 系统 ， 提 供 了 丰富 强大 的 功 
能 。Kubernetes 提 供 了 以 下 类 型 的 数据 卷 : 


e EmptyDir 


e HostPath 

e GCE Persistent Disk 

e Aws Elastic Block Store 
e NFS 

e iSCSI 

e Flocker 

e GlusterFS 

e RBD 

e Git Repo 

e Secret 

e Persistent Volume Claim 


。 Downward API 


7.2 ”本 地 数据 卷 


Kubernetes 中 有 两 种 类 型 的 数据 卷 ， 它 们 只 能 作用 于 本 地 文件 系 
统 ， 我 们 称 为 本 地 数据 卷 。 本 地 数据 卷 中 的 数据 只 会 存在 于 一 台 机 器 
上 ， 所 以 当 Pod 发 生 迁 移 的 时 候 ， 数 据 便 会 丢失， 无 法 满足 真正 的 数据 
持久 化 要 求 。 但 是 本 地 数据 卷 提 供 了 其 他 用 途 ， 比 如 Pod 中 容器 的 文件 


共享 
入 


， 或 者 共享 宿主 机 的 文件 系统 。 


‘oh 


7.2.1 EmptyDir 


EmptyDir 从 名 称 上 的 意思 看 是 空 的 目录 ， 它 是 在 Pod 创 建 的 时 候 新 
建 的 一 个 目录 。 


如 果 Pod 配 置 了 EmptyDir 数 据 卷 ， 在 Pod 的 生命 周期 内 都 会 存在 ， 当 
Pod 被 分 配 到 Node 上 的 时 候 ， 会 在 Node 上 创建 EmptyDir 数 据 卷 ， 并 挂 载 
到 Pod 的 容器 中 。 只 要 Pod 存 在 ，EmptyDir 数 据 卷 都 会 存在 〈 容 器 删除 不 
会 导致 EmptyDir 数 据 卷 丢 失 数 据 ) ， 但 是 如 果 Pod 的 生命 周期 终结 (Pod 
被 删除 ) ，EmptyDir 数 据 卷 也 会 被 删除 ， 并 且 永 久 丢 失 。 








EmptyDir 数 据 卷 非 常 适合 实现 Pod 中 容器 的 文件 共享 。Pod 的 设计 提 
供 了 一 个 很 好 的 容器 组 合 的 模型 ， 容 器 之 间 各 司 其 职 ， 通 过 共享 文件 目 
录 来 完成 区 互 ， 比 如 可 以 通过 一 个 专职 日 志 收 集 容 妖 ， 在 每 个 pod 中 和 
业务 容器 中 进行 组 合 ， 来 完成 日 志 的 收集 和 汇总 。 





我 们 创建 一 个 Pod，Pod 中 包含 两 个 容器 ， 容 器 Synthetic-logger 写 日 
志 到 /var/log 目 录 ， 而 容器 sidecar-log-collector 负 责 收 集 /var/log 目 录 下 的 
日 志文 件 ， 然 后 导出 到 Elasticsearch， 其 中 的 /var/log 目 录 就 是 一 个 
EmptyDir 数 据 卷 ， 分 别 挂 载 到 两 个 容器 中 ， 从 而 实现 文件 共享 。 Pod 的 
定义 文件 如 下 : 


apiVersion: v1 
kind: Pod 


metadata: 


labels: 
example: logging-sidecar 
name: logging-sidecar -example 
spec: 
containers: 
- name: synthetic-logger 
image: ubuntu:14.04 
command: ["bash","-c","i=\"O\"; while true; do echo \" hostna 
/var/log/synthetic-count.log; date --rfc-3339 ns >> /var/log/synt 
i=$[$i+1]; done"] 
volumeMounts: 
- name: log-storage 
mountPath: /var/log 
- name: sidecar-log-collector 
image: gcr.io/google_containers/fluentd-sidecar-es:1.2 
resources: 
limits: 
cpu: 100m 
memory: 200Mi 
env: 
- name: FILES_TO_COLLECT 
value: "/var/log/synthetic-count.log /var/log/synthetic-dat 
volumeMounts: 
- name: log-storage 
readOnly: true 
mountPath: /var/log 


volumes: 


- name: log-storage 


emptyDir: {} 


7.2.2 HostPath 


HostPath 数 据 卷 人 允许 将 容器 答 主 机 上 的 文件 系统 挂 载 到 Pod 中 。 如 
果 Pod 需 要 使 用 宿主 机 上 的 某 些 文件 ， 可 以 使 用 HostPath 数 据 卷 。 








创建 一 个 Pod 需 要 使 用 宿主 机 的 SSL 证 书 ， 可 以 通过 创建 HostPath 数 
据 卷 ， 然 后 将 宿主 机 的 /etc/ssl/certs 目 录 挂 载 到 容器 中 ，Pod 的 定义 文件 
如 下 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: nginx 
spec: 
containers: 
- name: nginx 
image: nginx 
ports: 
- containerPort: 80 
protocol: TCP 
volumeMounts: 
- name: ssl-certs 


mountPath: /etc/ssl/certs 


readOnly: true 
volumes: 
- name: ssl-certs 
hostPath: 


path: /etc/ssl/certs 


7.3 ”网络 数据 卷 


Kubernetes 提 供 了 很 多 类 型 的 数据 卷 以 集成 第 三 方 的 存储 系统 ， 包 
括 一 些 非常 流行 的 分 布 式 文件 系统 ， 也 有 在 IaaS 平 台 上 提供 的 存储 文 
持 ， 这 些 存储 系统 都 是 分 布 式 的 ， 通 过 网 络 共 享 文件 系统 ， 因 此 我 们 称 
这 一 类 数据 卷 为 网 络 数据 卷 。 





网 络 数据 卷 能 够 满足 数据 的 持久 化 需求 ，Pod 通 过 配置 使 用 网 络 数 
气 卷 ， 每 次 Pod 创 建 的 时 候 都 会 将 存储 系统 的 远 端 文件 目录 挂 载 到 容 需 
中 ， 数 据 卷 中 的 数据 将 被 永久 保存 ， 即 使 Pod 被 删除 的 时 候 ， 只 是 除去 
挂 载 数据 人 疮 ， 数 据 卷 中 的 数据 仍然 保存 在 存储 系统 中 ， 并 且 当 新 的 Pod 
被 创建 的 时 候 ， 仍 是 挂 载 同样 的 数据 卷 。 


7.3.1 NES 


NFS (Network File System) 即 网 络 文件 系统 ， 是 FreeBSD 文 持 的 一 
种 文件 系统 ， 它 允许 网 络 中 的 计算 机 通过 TCP/IP 共 享 资源 。 在 NFS 的 应 
用 中 ， 本 地 NFS 的 客户 端 应 用 可 以 透明 地 读 写 位 于 远 端 NFS 服 务 器 上 的 
文件 ， 束 像 访 问 本 地 文件 一 样 。 





NEFS 数 据 卷 的 配置 参数 如 表 7-1 所 示 。 


表 7-1 NFS 数 据 卷 的 配置 参数 








参数 可 选项 说 明 

server E NEFS 的 服务 端 地 址 

path pm ce NFS 的 共享 目录 路 径 
是 否 只 读 ， 默 认为 

readOnly false CB ay ist Hy 
HJ 

示例 如 下 : 

apiVersion: v1 

kind: Pod 

metadata: 


name: nfs-web 
spec: 
containers: 
- name: web 
image: nginx 
ports: 
- name: web 
containerPort: 80 
volumeMounts: 
- name: nfs 


mountPath: "/usr/share/nginx/html" 


volumes: 
- name: nfs 
nfs: 
server: nfs-server.default.kube.local 


path: "/" 


7.3.2 iSCSI 


iSCSI 技术 是 一 种 由 IBM 公 司 研 究 开 发 的 ， 是 一 个 供 硬 件 设 备 使 用 
的 可 以 在 IP 的 上 层 运 行 的 SCSI 指 令 集 ， 这 种 指令 集合 可 以 实现 在 IP 网 络 
上 运行 SCSI 协 议 ， 使 其 能 够 在 诸如 高 速 千 兆 以 太 网 上 进行 路 由 选择 。 
iSCSI 技术 是 一 种 新 的 储存 技术 ， 该 技术 是 将 现 有 SCSI 接 口 与 以 太 网 络 
(Ethernet) 技术 结合 ， 使 服务 器 可 与 使 用 了 网 络 的 储存 装置 互相 交换 
资料 。 


iSCSI 数据 卷 的 配置 参数 如 表 7-2 所 示 。 


表 7-2  iSGCS1 数 据 卷 配 置 参 数 


参数 i 说 明 

targetPortal X iSCSI Target 服 务 地 址 

iqn iSCSI 的 IQN 号 

lun iSCSI 的 多 辑 单 元 号 

` 文件 系统 类 型 ，ext4、xfs 或 ntfs 

是 否 只 读 ， 默 认为 false〈 即 可 读 可 写 ) 


























示例 如 下 : 


apiVersion: v1 


kind: Pod 


metadata: 
name: iscsipd 
spec: 
containers: 
- image: kubernetes/pause 
name: iscsipd-ro 
volumeMounts: 
- mountPath: /mnt/iscsipd 
name: iscsipd-ro 
- image: kubernetes/pause 
name: iscsipd-rw 
volumeMounts: 
- mountPath: /mnt/iscsipd 
name: iscsipd-rw 
volumes: 
- iscsi: 
fsType: ext4 
ign: iqn.2001-04.com.example:storage.kube.sys1. xyz 
lun: 0 
readOnly: true 
targetPortal: 10.0.2.15:3260 
name: iscsipd-ro 
- iscsi: 
fsType: ext4 
ign: iqn.2001-04.com.example:storage.kube.sysi1. xyz 
lun: 1 


targetPortal: 10.0.2.15:3260 


name: iscsipd-rw 


7.3.3 GlusterFS 


GlusterFS 是 Scale-Out 存 储 解决 方案 Gluster 的 核心 ， 它 是 一 个 开源 的 
分 布 式 文件 系统 ， 上 有 具有 强大 的 横向 扩展 能 力 ， 通 过 扩展 能 够 支持 数 PB 
存储 容量 和 处 理 数 千 客 户 端 。GlusterFS 借 助 TCP/TP 或 InfiniBand RDMA 
网 络 将 物理 分 布 的 存储 资源 聚集 在 一 起 ， 使 用 单一 全 局 命名 空间 来 管理 
数据 。GlusterFS 基 于 可 推 登 的 用 户 空 间 设 计 ， 可 为 各 种 不 同 的 数据 负载 
提供 优异 的 性 能 。 


GlusterFS 数 据 卷 配置 参数 如 表 7-3 所 示 。 


表 7-3 GlusterFS 数据 卷 配 置 参数 





参数 可 选项 说 明 


| oa GlusterFS 服 务 端 对 应 
endpoints T Endpoint 


path B GlusterFS 数 据 卷 路 径 


ZEA, MUN 
=| XE HYN GE bi D t 
P E false《〈 即 可 读 可 写 ) 





示例 如 下 : 


apiVersion: v1 


kind: Endpoints 


metadata: 

name: glusterfs-cluster 
subsets: 
- addresses: 


- ip: 10.240.106.152 


ports: 
- port: 1 
- addresses: 


- ip: 10.240.79.157 

ports: 

- port: 1 

apiVersion: v1 
kind: Pod 
metadata: 

name: glusterfs 

spec: 

containers: 

- image: kubernetes/pause 
name: glusterfs 
volumeMounts: 

- mountPath: /mnt/glusterfs 
name: glusterfsvol 
volumes: 

- glusterfs: 

endpoints: glusterfs-cluster 


path: kube_vol 


readOnly: true 


name: glusterfsvol 


7.3.4 RBD (Ceph Block Device) 


Ceph 是 开源 、 分 布 式 的 网 络 存 储 ， 同 时 又 是 文件 系统 。Ceph 的 设 
计 目 标 是 蛙 越 的 性 能 、 可 笔 性 以 及 可 扩展 性 。Ceph 基 于 可 靠 的 、 可 扩展 
的 和 分 布 式 的 对 象 存 储 ， 通 过 一 个 分 布 式 的 集群 管理 元 数据 ， 符 合 
POSIX. RBD (Rados Block Device) 是 一 个 Linux 块 设备 驱动 ， 提 供 了 
一 个 共享 网 络 块 设备 ， 实 现 与 Ceph 的 交互 。RBD 在 Ceph 对 象 存储 的 集 
群 上 进行 条 带 化 和 复制 ， 提 供 可 靠 性 、 可 扩展 性 以 及 对 块 设备 的 访问 。 





Kubernetes 中 支持 RBD 方 式 ，RBD 数 据 卷 配置 的 参数 如 表 7-4 所 示 。 


表 7-4 RBD 数 据 卷 配置 参数 


参数 i 说 明 

monitors T Ceph Monitors 的 地 址 

image 分 Rados 镜像 名 称 

fsType J 文件 系统 类 型 ，ext4、xfs 或 ntfs 

pool L Rados Pool 名 称 ， 默 认 是 rbd 

user 3 Rados 用 户 名 ， 默 认 是 admin 

keyring : Rados 钥 匙 阁 文 件 的 路 径 ， 默 认为 /etc/ceph/keyring 
secretRef : Rados 用 户 认证 Secret， 默 认为 空 

readOnly : 是 否 只 读 ， 默 认为 false《〈 即 可 读 可 写 ) 






























































示例 如 下 : 


apiVersion: v1 
kind: Pod 


metadata: 


name: rbd 
spec: 
containers: 
- image: kubernetes/pause 
name: rbd-rw 
volumeMounts: 


- mountPath: /mnt/rbd 


name: rbdpd 
volumes: 
- name: rbdpd 
rbd: 


fsType: ext4 

image: foo 

keyring: /etc/ceph/keyring 
monitors: 

- 10.16.154.78:6789 

- 10.16.154.82:6789 

- 10.16.154.83:6789 

pool: kube 

readOnly: true 


user: admin 


7.3.5 Flocker 


Flocker 是 一 个 容器 数据 管理 工具 ， 作 为 ClusterHQ 公 司 2014 年 推出 
的 产品 ，Flocker 主 要 负责 Docker 容 器 及 其 数据 的 管理 。 从 功能 方面 而 


言 ，Flocker 是 一 个 数据 卷 管理 器 和 多 主机 的 Docker 和 集群 管理 工具 。 用 户 
可 以 通过 它 来 控制 数据 ， 实 现在 Docker 中 运行 数据 库 、 队 列 和 键 值 
(Key/Value) 存储 等 服务 ， 并 在 应 用 程序 中 轻松 使 用 这 些 服 务 。 


Flocker 数 据 卷 配置 参数 如 表 7-5 所 示 。 


表 7-5 Flocker 数据 卷 配置 参数 





参数 可 选项 说 明 
datasetName an Flocker 数 据 集 名 称 


示例 如 下 : 
apiVersion: v1 
kind: Pod 
metadata: 


name: flocker-web 
spec: 
containers: 
- name: web 
image: nginx 
ports: 
- name: web 
containerPort: 80 
volumeMounts: 
# name must match the volume name below 
- name: www-root 


mountPath: "/usr/share/nginx/html" 


volumes: 


- name: www-root 


flocker: 


datasetName: my-flocker-vol 


7.3.6 AWS Elastic Block Store 


Amazon Elastic Block Store (Amazon EBS) 在 AWS 云 中 提供 用 于 
Amazon ”EC2 实 例 的 持久 性 数据 的 块 级 存储 卷 。 如 果 Kubernetes 运 行 在 
AWS 之 上 ， 束 可 以 非常 方便 地 使 用 Amazon Elastic Block Store 作 为 数据 


YA 
卷 。 


Amazon Elastic Block Store 数 据 卷 的 配置 参数 如 表 7-6 所 示 。 


#7-6 Amazon Elastic Block Store 数 据 卷 配 置 参 数 


说 明 





volumeID 


EBS 数 据 卷 标 识 





fsType 


文件 系统 类 型 ，ext4、xfs 或 ntfs 





partition 


磁盘 挂 载 分 区 





readOnly 


示例 如 下 : 
apiVersion: v1 
kind: Pod 
metadata: 


name: test-ebs 
spec: 


containers: 








是 否 只 读 ， 默 认为 false〈 即 可 读 可 写 ) 





- image: gcr.io0/google_containers/test -webserver 
name: test-container 
volumeMounts: 
- mountPath: /test-ebs 
name: test-volume 
volumes: 
- name: test-volume 
# This AWS EBS volume must already exist. 
awsElasticBlockStore: 
volumeID: aws://<availability-zone>/<volume-id> 


fsType: ext4 


7.3.7 GCE Persistent Disk 


GCE Persistent Disk 是 GCE 提 供 的 持久 化 数据 的 服务 ， 如 果 
Kubernetes 运 行 在 GCE 之 上 ， 可 以 使 用 GCE Persistent Disk 作 为 数据 卷 。 


GCE Persistent Disk 数 据 卷 的 配置 参数 如 表 7-7 所 示 。 


表 7-7 GCE Persistent Disk 数 据 卷 配置 参数 


参数 i 说 明 

volumeID EBS 数 据 卷 标识 

fsType 站 文件 系统 类 型 ，ext4、xfs 或 ntfs 
Partition 磁盘 挂 载 分 区 

readOnly : 是 否 只 读 ， 默 认为 false〈 即 可 读 可 写 ) 























示例 如 下 : 


apiVersion: v1 


kind: Pod 
metadata: 

name: test-pd 

spec: 

containers: 

- image: gcr.io/google_containers/test -webserver 
name: test-container 
volumeMounts: 

- mountPath: /test-pd 
name: test-volume 

volumes: 

- name: test-volume 
# This GCE PD must already exist. 
gcePersistentDisk: 

pdName: my-data-disk 


fsType: ext4 


7.4 Persistent Volume 和 了 Persistent 
Volume Claim 
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有 时 候 并 不 关心 各 种 存储 实现 ， 只 和 希望 能 够 安全 可 靠 地 存储 数据 。 
Kubernetes 中 提供 了 Persistent Volume 和 Persistent Volume Claim 机 制 ， 这 
是 存储 消费 模式 。Persistent Volume 是 由 系统 管理 员 配 置 创建 的 一 个 数 
气 卷 ， 它 代表 了 东 一 类 存储 插件 实现 ， 可 以 是 NFS、iSCSI 等 ， 而 对 于 








通用 户 来 说 ， 通 过 Persistent Volume Claim 可 请 求 并 获得 合适 的 
Persistent Volume， 而 无 须 感 知 后 端的 存储 实现 。 


Persistent Volume Claim 和 Persistent Volume 的 关系 其 实 类 似 于 Pod 和 
Node，Pod 消 费 Node 的 资源 ，Persistent Volume Claim 则 是 消费 Persistent 
Volume 的 资源 。Persistent Volume 和 Persistent Volume Claim 相 互 关 联 ， 
有 着 完整 的 生命 周期 管理 。 


© HES 


系统 管理 员 规 划 并 创建 一 系列 的 Persistent Volume, Persistent 
Volume 在 创建 成 功 后 处 于 可 用 状态 。 


*。 绑 定 


用 户 创建 Persistent Volume Claim 来 声明 存储 请 求 ， 包 括 存 储 大 
小 和 访问 模式 。Persistent Volume Claim 创 建成 功 后 进入 等 待 状态 ， 
当 Kubernetes 发 现 有 新 的 Persistent Volume Claim 创 建 的 时 候 ， 就 会 
根据 条 件 查 找 Persistent Volume。 当 有 Persistent Volume 匹配 的 时 
候 ， 就 会 将 Persistent Volume Claim 和 Persistent Volume 进 行 绑 定 ， 
Persistent Volume 和 了 Persistent Volume Claim 都 进入 绑 定 状态 。 


Kubernetes 只 会 选择 可 用 状态 的 Persistent Volume， 并 且 采 取 最 小 满 
EIK, mA Persistent Volume 满 足 需 求 的 时 候 ，Persistent Volume 
Claim 将 处 于 等 待 阶段 。 比 如 现在 有 两 个 Persistent ”Volume 可 用 ， 一 


Persistent Volume 的 容量 是 50Gi， 一 个 Persistent Volume 的 容量 是 60Gi。 
那么 请 求 40Gi 的 Persistent Volume ”Claim 会 被 绑 定 到 50Gi 的 Persistent 
Volume， 而 请 求 100Gi 的 Persistent Volume Claim 则 处 于 等 待 状态 ， 直 到 
有 大 于 100Gi 的 Persistent Volume 出 现 (Persistent Volume 有 可 能 被 新 建 
或 者 被 回收 ) 。 


。 使 用 


创建 Pod 的 时 候 使 用 Persistent Volume Claim，Kubernetes 便 会 查 
询 其 绑 定 的 Persistent Volume， 去 调用 真正 的 存储 实现 ， 然 后 将 数 
据 卷 挂 载 到 Pod 中 。 





。 释 放 


当 用 户 删 除 Persistent Volume 所 绑 定 的 Persistent Volume Claim 
IN, Persistent Volume 则 进入 释放 状态 。 此 时 Persistent Volume 中 可 
能 残留 着 之 前 Persistent Volume Claim 使 用 的 数据 ， 所 以 Persistent 
Volume 并 不 可 用 ， 需 要 对 Persistent Volume 进 行 回 收 操作 。 


e 回收 


释放 的 Persistent Volume 需 要 回收 才能 再 次 使 用 ， 回 收 的 策略 
可 以 是 人 工 处 理 ， 或 者 由 Kubernetes 自 动 进行 清理 ， 如 清理 失败 ， 
Persistent Volume 会 进入 失败 状态 。 


综 上 所 述 ，Persistent Volume 的 状态 包括 如 下 几 项 。 


e Available: Persistent ”Volume 创 建成 功 后 进入 可 用 状态 ， 等 待 


Persistent Volume Claim 消 费 。 


。Bound: Persistent Volume 被 分 配 到 Persistent Volume Claim 进 行 绑 
定 ，Persistent Volume 进 入 绑 定 状态 。 


e Released: Persistent Volume 绑 定 的 Persistent Volume Claim 被 删 
除 ，Persistent Volume 进 入 释放 状态 ， 等 竺 回收 处 理 。 


。 Failed: Persistent Volume 执 行 自 动 清理 回收 策略 失败 后 ， 
Persistent Volume 会 进入 失败 状态 。 


Persistent Volume Claim 的 状态 包括 如 下 几 项 。 


e Pending: Persistent Volume Claim 创 建成 功 后 进入 等 待 状态 ， 等 待 
绑 定 Persistent Volume。 


。 Bound: 分 配 Persistent Volume 给 Persistent Volume Claim 进 行 绑 
SE, Persistent Volume Claim 进 入 绑 定 状态 。 


7.4.1 创建 Persistent Volume 


Persistent ”Volume 代表 可 靠 的 存储 系统 ， 从 实现 上 来 说 ，Persistent 
Volume 实 际 上 惑 是 复 用 了 已 有 的 数据 卷 实 现 ， 配 置 方法 也 是 一 致 的 ， 
Persistent Volume 目 前 支持 以 下 类 型 . 





e GCE Persistent Disk 


e AWS Elastic Block Store 

e NFS 

e iSCSI 

e RBD (Ceph Block Device) 
e GlusterFS 

e HostPath: 只 适合 测试 使 用 


Persistent Volume 是 需要 事先 创建 好 的 ， 这 一 般 来 说 是 系统 管理 员 
的 工作 。 系 统管 理 员 根据 实际 情况 ， 创 建 一 系列 可 用 的 Persistent 
Volume。 比 如 Kubemetes 是 运行 在 AWS 之 上 的 ， 购 买 了 10 个 100Gi 的 
Amazon EBS， 那 就 可 以 创建 10 个 容量 为 100Gi 的 Persistent Volume. 





创建 Persistent Volume 的 时 候 需 要 指定 数据 卷 的 容量 、 访 问 模 式 和 
回收 策略 。 


Bx 是 


Persistent Volume 通 过 设置 资源 容量 ， 然 后 Persistent Volume Claim 
在 请 求 的 时 候 指 定 资 源 需 求 来 进行 下 配 。 比 如 现在 有 1 个 容量 为 10Gi 的 
Persistent Volume 和 1 个 容量 为 20Gi 的 Persistent | Volume, Persistent 
Volume ”Claim 请 求 15Gi， 台 匹配 了 20Gi 的 Persistent Volume. FH fil 
Persistent Volume 的 资源 容量 只 有 一 个 属性 ， 就 是 存储 大 小 : 








capacity: 


storage: 20Gi 


. 访问 模式 


。ReadWriteOnce: 数据 卷 能 够 在 一 个 节点 上 挂 载 为 读 写 日 录 。 

。ReadOnlyMany: 数据 卷 能 够 在 多 个 节点 上 挂 载 为 只 读 目 录 。 

。 ReadWriteMany: 数据 卷 能 够 在 多 个 节点 上 挂 载 为 读 写 目 
录 。 


* 回 收集 略 


当前 文 持 的 回收 策略 如 下 所 示 。 





e Retain: Persistent Volume 在 释放 后 ， 需 要 人 工 进行 回收 操 
ee 

e Recycle: Persistent Volume 在 释放 后 ，Kubernetes 上 自动 进行 清 
理 ， 清 理 成 功 后 Persistent ”Volume 则 可 以 再 次 绑 定 使 用 。 目 前 只 有 
NFS 和 HostPath 类 型 的 Persistent Volume 支 持 回 收 策略 。 当 执行 回收 
策略 的 时 候 ， 会 创建 一 个 Persistent Volume Recycler Pod， 这 个 Pod 
执行 清理 动作 ， 即 删除 Persistent Volume 目录 下 的 所 有 文件 〈 包 括 
隐藏 文件 〉。 





现在 创建 一 个 Persistent Volume，Persistent Volume 的 定义 文件 nfs- 


pv.yaml: 


apiVersion: v1 


kind: PersistentVolume 
metadata: 
name: nfs-pv 
labels: 
type: nfs 
spec: 
Capacity: 
storage: 5Gi 
accessModes: 
- ReadWriteMany 
nfs: 
server: nfs-server 


path: / 


Persistent ”Volume 的 定义 中 使 用 了 NEFS， 配 置 参 数 同 NFS 数 据 卷 一 
致 ， 另 外 设置 了 存储 容量 为 5Gi， 访 问 权 限 为 ReadWriteMany。 


通过 定义 文件 创建 Persistent Volume: 


$ kubectl create -f nfs-pv.yaml 


persistentvolume "nfs-pv" created 


创建 成 功 后 可 以 查询 创建 的 Persistent Volume, Persistent Volume 的 
状态 为 Available: 


$ kubectl describe persistentvolume nfs-pv 
Name: nfs-pv 


Labels: type=nfs 


Status : Available 
Claim: 
Reclaim Policy: Retain 
Access Modes: RWX 
Capacity: 5Gi 
Message: 
source: 
Type: NFS (an NFS mount that lasts the lifetime of a pod) 
Server :nfs-server 
Path: / 
ReadOnly: false 


7.4.2 ”创建 Persistent Volume Claim 


Persistent Volume Claim 指 定 所 需要 的 存储 大 小 ， 然 后 Kubernetes 会 
选择 满足 条 件 的 Persistent Volume 进 行 绑 定 。 


现在 创建 Persistent Volume Claim 来 消费 刚 创建 的 Persistent 
Volume, Persistent Volume Claim 的 定义 文件 test-pvc.yaml: 


apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
name: test-pvc 
spec: 


accessModes: 


- ReadwriteMany 
resources: 
requests: 


storage: 3Gi 


通过 定义 文件 创建 Persistent Volume Claim: 


$ kubectl create -f my-pvc.yaml 


persistentvolumeclaim "my-pvc" created 


创建 成 功 后 可 以 查询 创建 的 Persistent Volume Claim: 


$ kubectl describe persistentvolumeclaim my-pvc 
Name: my-pvc 
Namespace: default 


Status: Bound 


Volume: nfs-pv 
Labels: <none> 
Capacity: 5G1 


Access Modes: RWX 


可 以 看 到 ，Persistent Volume Claim CAA Persistent Volume 为 
nfs-pv， 然 后 查询 Persistent Volume 的 状态 为 Bound: 


$ kubectl describe persistentvolume nfs-pv 


Name: nfs-pv 
Labels: type=nfs 
Status: Bound 


Claim: default/my -pvc 


Reclaim Policy: Retain 
Access Modes: RWX 
Capacity: 5Gi 
Message: 
Source: 
Type: NFS (an NFS mount that lasts the lifetime of a pod) 
Server:nfs-server 
Path: / 
Readonly:false 


最 后 创建 Pod 来 使 用 Persistent Volume Claim，Pod 的 定义 文件 : 


apiVersion: v1 
kind: Pod 
metadata: 

name: busybox 

labels: 
app: busybox 

spec: 

containers: 

- name: busybox 
image: busybox 
command: 

- sleep 
- 3600 
volumeMounts: 


- mountPath: /busybox-data 


name: data 
volumes: 
- name: data 
persistentVolumeClaim: 


ClaimName: my-pvc 


75 ”信息 数据 卷 


Kubernetes 中 有 一 些 数据 卷 ， 主 要 用 来 给 容器 传递 配置 信息 ， 我 们 
称 之 为 信息 数据 卷 ， 比 如 Secret 和 Downward  _ API， 都 是 将 Pod 的 信息 以 
文件 形式 保存 ， 然 后 以 数据 卷 方 式 挂 载 到 容器 中 ， 容 器 通过 读 取 文件 获 
取 相 应 的 信息 。 从 功能 设计 上 来 说 ， 是 有 点 偏离 数据 卷 的 本 意 ， 数 据 卷 
是 用 来 持久 化 数据 的 ， 或 者 进行 文件 共享 的 。 未 来 版 本 可 能 会 对 这 部 分 
进行 重 构 ， 将 信息 数据 卷 提供 的 功能 放 在 更 合适 的 地 方 。 





7.5.1 Secret 


Kubernetes 提 供 了 Secret 来 处 理 敏 感 数 据 ， 比 如 密码 、Token 和 密 
钥 ， 相 比 于 直接 将 敏感 数据 配置 在 Pod 的 定义 或 者 镜像 中 ，Secret 提 供 了 
更 加 安全 的 机 制 ， 防 止 数据 泄露 。 





Secret 的 创建 是 独立 于 Pod 的 ， 以 数据 卷 的 形式 挂 载 到 Pod 中 ，Secret 
的 数据 将 以 文件 的 形式 保存 ， 容 器 通过 读 取 文件 可 以 获取 需要 的 数据 。 


Secret 的 类 型 有 3 种 。 


e Opaque: 目 定义 数据 内 容 ， 默 认 值 。 


。 kubernetes.io/service-account-token: Service Account 的 认证 内 容 ， 
可 参考 10.3 节 。 


e kubernetes.io/dockercfg: Docker 镜 像 仓 库 的 认证 内 容 ， 可 参考 4.3.1 


节 。 
现在 有 一 个 应 用 需要 获取 一 个 账号 密码 ， 即 可 以 通过 Secret 来 实 
现 : 


username: my-username 


password: my-password 


因为 是 自 定义 数据 内 容 ， 所 以 Secret 的 类 型 是 Opaque， 配 置 的 数据 
是 一 系列 Key/Value 对 ， 其 中 Value 需要 使 用 Base64 加 密 ，Secret 定 义 文 
件 secret.yaml: 


apiVersion: v1 
kind: Secret 
metadata: 
name: mysecret 
type: Opaque 
data: 
username: bXktdXNlcm5hbwUK 


password: bXktcGFzc3dvcmQkK 


通过 定义 文件 创建 Secret: 


$ kubectl create -f secret.yaml 


secret "mysecret" created 


创建 成 功 后 查询 Secret: 


$ kubectl describe secret mysecret 
Name: mysecret 

Namespace: default 

Labels: <none> 

Annotations: <none> 


Type: Opaque 


Data 


password: 12 bytes 


username: 12 bytes 


然后 创建 Pod 使 用 该 Secret，Pod 的 定义 文件 : 


apiVersion: v1 
kind: Pod 
metadata: 

name: busybox 

labels: 

app: busybox 

spec: 

containers: 

- name: busybox 


image: busybox 


command: 

- sleep 

- "3600" 

volumeMounts: 

- mountPath: /secret 
name: secret 
readOnly: true 

volumes: 
- name: secret 
secret: 


secretName: mysecret 


Pod 的 定义 中 声明 了 Secret 数 据 卷 ， 并 且 将 Secret 数 据 卷 挂 载 到 了 Pod 
容器 中 的 /secret 目 录 下 ， 因 为 Secret 包 含 两 个 Key/Value 对 ， 在 容器 
的 /secret 目 录 中 分 别 有 两 个 文件 username 和 password， 文 件 的 内 容 束 是 
解密 后 的 数据 : 


$ kubectl exec busybox -- ls /secret 

password 

username 

$ kubectl exec busybox -- cat /secret/username 


my-username 


$ kubectl exec busybox -- cat /secret/password 


my - password 


7.5.2 Downward API 


Downward API 可 以 通过 环境 变量 的 方式 告诉 容器 Pod 的 信息 (可 参 
考 4.3.3 节 ) ， 另 外 ， 也 可 以 通过 数据 卷 方式 传 值 ，Pod 的 信息 将 会 以 文 
件 的 形式 通过 数据 卷 挂 载 到 容器 中 ， 在 容 右 中 可 以 通过 读 取 文件 获取 信 
A, 目前 支持 : 








。Pod 的 名 称 。 

。Pod 的 Namespace。 
。Pod 的 Label。 

。Pod 的 Annotation 。 


创建 Pod 使 用 Downward ” API 数据 卷 ，Pod 的 定义 文件 downwardapi- 


volume.yaml: 


apiVersion: v1 
kind: Pod 
metadata: 
name: downwardapi-volume 
labels: 
zone: us-est-coast 
cluster: test-cluster1 
rack: rack-22 
annotations: 


build: two 


builder: 


spec: 


john-doe 


containers: 


- name: 


client-container 


image: ubuntu:14.04 


command: ["/bin/bash", "-c", "while true; 


volumeMounts: 


- name: podinfo 


mountPath: /podinfo/ 


readOnly: false 


volumes: 


- name: 


podinfo 


downwardAPL: 


items: 


path: "pod_name" 
fieldRef: 

fieldPath: metadata.name 
path: "pod_namespace" 
fieldRef: 

fieldPath: metadata.namespace 
path: "pod_labels" 
fieldRef: 

fieldPath: metadata.labels 
path: "pod_annotations" 
fieldRef: 


fieldPath: metadata.annotations 


do sleep 5; done 


Pod 定 义 中 声明 了 Downward API 数据 卷 ， 分 别 引用 了 Pod 的 相关 属 
性 ， 然 后 将 数据 卷 挂 载 到 容器 /podinfo 目 录 下 。 在 Pod 创 建 运行 后 ， 就 可 


以 查询 /podinfo 目 录 下 的 数据 : 


$ kubectl exec downwardapi-volume -- ls /podinfo 


pod_annotations 
pod_labels 
pod_name 


pod_namespace 


$ kubectl exec downwardapi-volume 


downwardapi-volume 


$ kubectl exec downwardapi-volume 


default 


$ kubectl exec downwardapi-volume 
cluster="test-cluster1" 


rack="rack-22" 


$ kubectl exec downwardapi-volume 
build="two" 


builder="john-doe" 


kubectl.kubernetes.io/last-applied-configuration="... 


cat /podinfo/pod_name 


cat /podinfo/pod_namespace 


cat /podinfo/pod_labels 


cat /podinfo/pod_annotations 


kubernetes.10/config.seen="2015-11-02T18: 29:57 .509960318+08:00" 


kubernetes.10/config.source="api" 


7.5.3 Git Repo 


Kubernetes 支 持 将 Git 仓 库 下 载 到 Pod 中 ， 目 前 是 通过 Git Repo 数 据 卷 
实现 ， 即 当 Pod 配 置 Git Repo 数 据 卷 时 ， 就 下 载 配置 的 Git 仓 库 到 Pod 的 数 
据 卷 中 ， 然 后 挂 载 到 容器 中 。 我 们 现在 定义 一 个 Pod 使 用 Git ”Repo 数 据 
卷 ，Pod 的 定义 文件 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: busybox 
labels: 
app: busybox 
spec: 
containers: 
- name: busybox 
image: busybox 
command: 
- sleep 
- "3600" 
volumeMounts: 
- mountPath: /config 
name: busybox-config 
volumes: 
- name: busybox-config 


gitRepo: 


repository: https://github.com/wulonghui/busybox-config.git 


revision: master 


Pod 的 定义 中 声明 了 Git Repo 数 据 卷 ， 然 后 挂 载 到 容器 的 /config 目 录 
下 ， 在 Pod 运 行 后 ， 即 会 下 载 指定 的 Git 仓 库 到 /config 目 录 下 : 


$ kubectl exec busybox -- ls /config 


busybox-config 


第 8 章 
访问 Kubernetes API 


Kubernetes 规 范 和 健全 的 API 模 型 ， 为 Kubernetes 的 使 用 和 扩展 提供 
了 非常 好 的 支持 。 


本 章 首先 说 明 Kubernetes 提 供 的 API 对 象 以 及 元 数据 ， 然 后 介绍 
Kubernetes API 的 访问 方式 ， 最 后 详细 前 述 Kubernetes 的 命令 行 工 具 ， 帮 
助 读者 真正 掌握 如 何 使 用 Kubernetes。 


8.1 API 对 象 与 元 数据 


Kubernetes 中 的 很 多 功能 是 通过 API 对 象 来 实现 的 ， 在 前 面 的 章节 中 
我 们 已 经 创建 过 许多 API 对 象 ， 包 括 Pod、Replication Controller, Service 
和 Secret 等 。 在 定义 API 对 象 的 时 候 需 要 分 别 声明 API 版 本 〈apiVersion ) 
和 类 型 (kind) ， 当 前 版 本 Kubernetes ”v1.1.1 支 持 的 API 对 象 的 API 版 本 
和 类 型 如 下 所 示 : 








。V1/Pod 
e v1/ReplicationController 
e vl/Service 


e v1/Endpoints 


e v1/Events 

e v1/Node 

e v1/Namespace 

e v1/Secret 

e v1/ServiceAccount 

e v1/Persistent Volume 

e v1/PersistentVolumeClaim 

e v1/LimitRange 

e v1/ResourceQuota 

e extensions/v1beta1/Deployment 
e extensions/v1beta1/HorizontalPodAutoscaler 
e extensions/v1beta1/Ingress 

e extensions/v1beta1/Job 


e extensions/v1betal/Daemonset 


API 对 象 的 元 数据 用 来 定义 API 对 象 的 基本 信息 ， 体 现在 定义 中 的 
metadata 字 段 ， 包 含 以 下 属性 。 


。namespace: 指定 API 对 象 所 在 的 Namespace。 


。name: 指定 API 对 象 的 名 称 。 

e labels: 设置 API 对 象 的 Label。 
‘annotations: 设置 API 对 象 的 Annotation 。 
Namespace 


Namespace 是 Kubernetes 提 供 的 多 租户 ， 不 同 的 项 目 、 团 队 或 者 用 户 
可 以 通过 Namespace 进 行 区 分 管理 ， 并 且 设 置 安全 控制 和 其 他 策略 。 绝 
大 部 分 API 对 象 〈 除 了 Node) 归属 于 Namespace，API 对 象 通 
过 .metadata.namespace 指 定 Namespace， 如 果 没 有 指定 Namespace， 那 么 
就 是 归属 于 默认 Namespace default. 


Name 


名 称 是 一 个 重要 的 属性 ， 是 人 类 可 读 的 ， 元 数据 中 
的 .metadata.name 用 于 指定 API 对 象 的 名 称 。Kubernetes 系 统 中 的 API 对 象 
必须 能 够 通过 名 称 唯 一 标识 ，Kubernetes 包 含 Namespace 的 逻辑 层级 ， 大 
部 分 API 对 象 必须 归属 于 Namespace， 所 以 这 些 API 对 象 的 名 称 必须 在 
Namespace 内 唯一 。 而 另外 对 于 Node 和 Namespace 来 说 ， 需 要 在 
Kubernetes 系 统 中 唯一 。 


Label 





Label 用 于 区 分 API 对 象 的 Key/Value 对 ，Label 存 放 的 应 该 是 具有 标 
识 性 的 数据 ，Kubernetes 通 过 Label 可 以 对 API 对 象 进行 选择 。Replication 
Controller 和 Service 都 是 通过 Label 关 联 Pod， 而 Pod 也 可 以 通过 Label 选 择 
Node。 


Annotation 


Annotation 用 于 存放 用 户 的 自 定义 数据 ，Annotation 存 放 的 是 非 标 识 
的 数据 ， 所 以 不 能 像 Label 一 样 进行 对 象 选 择 。 但 是 Annotation 的 数据 可 
以 是 长 数据 ， 可 以 有 结构 或 者 无 结构 ， 作 为 Label 的 一 种 补充 ， 
Annotation 也 是 Key/Value 对 : 





annotations: 
key1: value1 


key2: value2 


8.2 ”如 何 访问 Kubernetes API 


使 用 Kubernetes 都 需要 访问 其 API， 而 Kubernetes API Server 作 为 
Kubernetes 系 统 的 入 口 ， 以 REST API 接 口 方 式 提供 给 外 部 调用 ， 所 以 访 
问 Kubernetes API 实际 上 就 是 调用 Kubernetes API Servere HP 
Kubernetes API Server 集 成 了 Swagger， 可 以 通过 界面 查询 所 有 API 的 详 
细 人 信息 Chttp://kube-master:8080/swagger-ui/) ， 如 图 8-1 所 示 。 


} Swagger http://kube-master-8080/swagger-wV./../swagger-spec/ japixsy | 时 2 


api: get available API versions Show/Hide List Operations Expand Operations Raw 
apis : get available API versions 

extensions : get information of a group 

v1: API at /api/v1 


vibeta’ ; API at /apis/extensions/v1beta1 


version ; git code version from which this is built 


H swagger a CL . 











图 8-1 Kubernetes# nm Swagger #2 EAP I & i 


除 此 之 外 ， 社 区 中 封装 提供 了 各 种 开发 语言 的 Kubernetes 客 户 端 Lib 
包 ， 如 图 8-1 所 示 ， 可 以 使 用 这 些 Lib 包 来 开发 程序 以 访问 Kubernetes 
API. 


#8-1 Kubernetes 客 户 端 Lib 包 


Kubernetes Client https://github.com/kubernetes/kubernetes/tree/v1.1.1/pkg/client 
Amdatu Kubernetes https://bitbucket.org/amdatulabs/amdatu-kubernetes 








kubernetes-client https://github.com/fabric8io/kubernetes-client 


kubeclient https://github.com/abonas/kubeclient 
kubernetes-client https://github.com/maclof/kubernetes-client 








kubernetes-api-php-client https://github.com/devstub/kubernetes-api-php-client 


node-kubernetes-client https://github.com/tenxcloud/node-kubernetes-client 


Net::Kubernetes Perl https://github.com/kubernetes/kubernetes/blob/v1.1.1/docs/devel/ 
client-libraries.md 





8.3 ”使 用 命令 行 工 具 Kkubectl 


Kubernetes 提 供 了 命令 行 工具 kubectl， 它 提供 了 非常 简洁 快速 的 方 


法 来 访问 Kubernetes API， 可 以 满足 大 部 分 对 Kubernetes 的 操作 。kubect 
可 以 从 Kubernetes 发 布 包 中 获取 ， 其 中 platforms 目 录 下 放置 着 各 个 平台 
的 kubectl 可 执行 文件 : 





$ wget https://github.com/kubernetes/kubernetes/releases/download 
$ tar zxvf kubernetes.tar.gz 


$ cd kubernetes/platforms 


命令 行 工具 kubect 包 含 的 命令 如 表 8-2 所 示 。 


表 8-2 kubect1 命 令 


命令 说 明 
kubectl config 操作 Kubeconfig 文 件 


kubectl version 查询 Kubernetes 版 本 信息 

kubectl api-versions 查询 Kubernetes 支 持 的 API 版 本 信息 
kubectl cluster-info 查询 Kubernetes 运 行 环境 信息 
kubectl proxy 为 Kubernetes API Server 启 动 服务 代理 
kubectl create 创建 API 对 象 

kubectl delete 删除 API 对 象 

kubectl apply 更 新 API 对 象 

kubectl patch 为 API 对 象 打 补丁 

kubectl label 操作 API 对 象 的 Label 

kubectl annotate 操作 API 对 象 的 Annotation 

kubectl logs 获取 Pod 中 容器 的 输出 日 志 

kubectl autoscale 执行 Pod 的 自动 伸缩 

kubectl rolling-update 执行 Pod 的 滚动 升级 

kubectl scale 执行 Pod 的 弹性 伸缩 

kubectl attach 连接 Pod 中 启动 的 容器 

kubectl exec 在 Pod 的 容器 中 执行 命令 

kubectl port-forward 为 Pod 设 置 端口 转发 

kubectl run 创建 Replication Controller 












































kubectl expose 创建 Service 


8.3.1 配置 Kubeconfig 


使 用 kubect 命 令 行 的 时 候 首先 需要 配置 Kubeconfig 文 件 ， 用 于 配置 
ee API, €4%Kubemetes API Server 的 URL 和 认证 信息 
并 且 可 以 设置 不 同 的 上 下 文 环境 ， 快 速 切换 访问 环境 。 


下 面 是 一 个 Kubeconfig 文 件 示例 : 


apiVersion: v1 
kind: Config 
clusters: 
- Cluster: 
certificate-authority: /etc/kubernetes/ca/ca.crt 
server: https://kube-master : 6443 
name: k8s 
users: 
- name: k8s-client 
user: 
client-certificate: /etc/kubernetes/ca/client.crt 
client-key: /etc/kubernetes/ca/client.key.insecure 
- name: k8s-admin 
user: 
password: test 
username: k8s-admin 
contexts: 
- context: 
cluster: k8s 
user: k8s-admin 


namespace: default 


name: default 
current-context: default 


preferences: {} 
Kubeconfig 文 件 的 定义 中 包含 以 下 关键 部 分 。 
e clusters: 设置 Kubernetes API Server 的 访问 URL 和 相关 属性 。 
e users: 设置 访问 Kubernetes API Server 的 认证 信息 。 
。contexts: 设置 kubelet 执 行 上 下 文 。 
。current-context: 设置 kubelet 执 行当 前 上 下 文 。 
。preferences: 设置 kubelet 其 他 属性 。 


Kubeconfig 文 件 可 以 手动 进行 编辑 ， 也 可 以 通过 kubectl config 命 令 
进行 查询 和 设置 ， 如 表 8-3 所 示 。 
表 8-3 kubect1 config 命 令 
命令 说 明 


kubectl config view 查看 Kubeconfig 文 件 


kubectl config set-cluster 设置 Kubeconfig 的 clusters 











kubectl config set-credentials 设置 Kubeconfig 的 users 








kubect config set-context 设置 Kubeconfig 的 contexts 





























kubectl config use-context 设置 Kubeconfig 的 current-context 


8.3.2 ”Kubernetes 探 作 


kubectl version 


kubectl version 命 令 用 来 查询 Kubermetes 的 版 本 信息 ， 包 括 客 户 端 和 
服务 端 ， 这 在 问题 定位 的 时 候 特 别 有 帮 助 : 


$ kubectl version 

Client Version: version.Info{Major:"1",Minor:"1",GitVersion: "v1.1 
GitTreeState:"clean"} 

Server Version: version.Info{Major:"1",Minor:"1",GitVersion:"v1i.1 


GitTreeState:"clean"} 


kubectl api-versions 


kubectl api-versions 命 令 可 以 查询 Kubernetes 文 持 的 API 版 本 : 


$ kubectl api-versions 
extensions/vibetat 


vi 


kubectl cluster-info 





kubectl cluster-info 命 令 可 以 查询 Kubernetes 的 运行 环境 信息 ， 包 括 
Kubernetes API Server 和 平台 级 别 Service (kubernetes.io/cluster- 
service=true) 的 地 址 : 


$ kubectl cluster-info 

Kubernetes master is running at http://k8s-master : 8080 

KubeDNS is running at http://k8s-master :8080/api/vi/proxy/namespa 
kube-dns 

KubeUI is running at http://k8s-master :8080/api/v1/proxy/namespac 


kube-ui 


kubectl proxy 


kubectl proxy 命 令 可 以 为 Kubernetes API Server 在 本 地 启动 一 个 代理 
服务 ， 访 问 这 个 代理 服务 就 可 以 访问 Kubernetes API Server. 


执行 kubectl proxy 的 时 候 可 以 指定 监听 端口 和 API 访 问 前 绥 : 


$ kubectl proxy --port=8011 --api-prefix=/k8s-api 


Starting to serve on 127.0.0.1:8011 


kubectl proxy 启 动 后 就 可 以 通过 http://127.0.0.1:8011/k8s-api 访 问 到 代 
理 服务 ， 从 而 访问 Kubernetes API Server. 


8.3.3 ”API 对 象 操作 

kubectl 命 令 行 可 以 操作 API 对 象 ， 执 行 的 时 候 需 要 指定 API 对 象 的 类 
型 ， 类 型 可 以 用 单数 形式 、 复 数 形式 或 者 简写 形式 ， 具 体 如 下 所 示 : 

e pod/pods/po 

e replicationcontroller/replicationcontrollers/rc 

e daemonset/daemonsets/ds 

e service/services/Svc 


e endpoints/ep 


e event/events/ev 

e node/nodes/no 

* namespace/namespaces/ns 

e secret/secrets 

e serviceaccount/serviceaccounts 

e persistentvolume/persistentvolumes/pv 

e persistentvolumeclaim/persistentvolumeclaims/pvc 
e limitrange/limitranges/limits 

e resourcequota/resourcequotas/quota 

e componentstatuses/cs 

e daemonset/daemonsets/ds 

e deployment/deployments 

e horizontalpodautoscaler/horizontalpodautoscalers/hpa 
e ingress/ingresses/ing 

e job/jobs 

kubectl create 


kubectl create 命令 用 来 创建 API 对 象 ， 格 式 支持 JSON 和 YAML 。 使 


用 kubectl create 主 要 是 通过 定义 文件 进行 创建 : 
$ kubectl create -f /path/to/file 
可 通过 传递 标准 输入 〈stdin) 进行 创建 : 
$ cat /path/to/file | kubectl create -f - 
kubectl create 文 持 连续 创建 多 个 API 对 象 : 


$ kubectl create -f /path/to/file1 -f /path/to/file2 


kubectl get 


kubectl get 命 令 可 以 用 来 查询 各 类 API 对 象 的 信息 。 








kubectl get 可 以 查询 指定 API 对 象 : 
$ kubectl get TYPE NAME 

可 以 查询 一 个 类 型 的 所 有 API 对 象 : 
$ kubectl get TYPE 

也 可 以 同时 查询 多 个 类 型 ， 类 型 之 间 用 ,分 隔 : 
$ kubect1 get TYPE1,TYPE2 


kubectl get3¢ FPM Label ffi wt APIXY &: 


$ kubectl get TYPE --selector key1=value1, key2=value 








默认 情况 下 ，kubect get 只 会 显示 简要 信息 ， 以 下 方式 可 以 显示 详 


细 信 A : 


$ kubectl get TYPE NAME --output json 


$ kubectl get TYPE NAME --output yaml 





kubect get 也 支持 通过 Go Template® # JSON Path 提 取 指 定 信息 : 


$ kubectl get TYPE NAME --output go-template=... 


$ kubectl get TYPE NAME --output jsonpath=... 


kubectl describe 





kubectl describe 命 令 可 以 用 来 查询 各 类 API 对 象 的 概况 信息 ， 支 持 批 
量 查 询 和 指定 查询 : 


$ kubectl describe TYPE 


$ kubectl describe TYPE NAME 


kubectl delete 


kubectl delete 命 令 用 来 删除 API 对 象 ， 删 除 的 时 候 可 以 指定 API 对 象 
进行 删除 : 


$ kubectl delete TYPE NAME 
也 可 以 通过 定义 文件 删除 : 
$ kubectl delete -f /path/to/file 


另外 ，kubectl delete 命 令 可 以 进行 批量 删除 ， 多 个 API 对 象 类 型 之 间 
用 ,分 隔 : 


$ kubectl delete TYPE1, TYPE2 --all 
或 者 通过 Label 筛 选 删除 : 
$ kubectl delete TYPE1,TYPE2 --selector key1=value1, key2=value 


kubectl apply 


kubectl apply 命 令 可 以 用 来 更 新 已 创建 的 API 对 象 ， 主 要 是 通过 定义 
文件 进行 修改 : 


$ kubectl apply -f /path/to/file 
也 可 通过 传递 标准 输入 (stdin〉 进 行 修改 : 
$ cat /path/to/file | kubectl apply -f - 


kubectl replace 





kubectl replace 命 令 与 kubectl apply 类 似 ， 都 可 以 用 来 更 新 已 创建 的 
API 对 象 : 


$ kubectl apply -f /path/to/file 


但 有 时 候 API 对 象 的 有 些 属 性 无 法 直接 更 新 ， 这 时 候 可 以 使 用 
kubectl replace 命 令 强 制 进行 重建 以 实现 更 新 : 


$ kubectl apply -f /path/to/file --force 


kubectl edit 


kubectl edit 命 令 可 以 用 来 编辑 已 创建 的 API 对 象 ， 使 用 kubectl edit 命 


令 的 时 候 会 开启 一 个 编辑 嚣 。 通 过 编辑 器 可 以 方便 地 对 API 对 象 进行 编 
辑 ， 默 认 的 编辑 器 是 VI， 可 以 通过 环境 变量 KUBE_EDITOR 选 择 其 他 编 
辑 器 : 
$ KUBE_EDITOR="nao" kubectl edit TYPE NAME 

在 编辑 器 中 默认 显示 的 格式 是 YAML， 也 可 以 指定 为 JSON: 
$ kubectl edit TYPE NAME --output json 


kubectl patch 


kubectl patch 命 令 可 以 给 API 对 象 打 补 本 ， 即 修改 指定 属性 ， 这 样 可 
以 非常 方便 地 修改 API 对 象 ， 其 中 PATCH 要 使 用 JSON 格 式 : 


$ kubectl patch TYPE --patch PATCH 
kubectl label 


kubectl label 命 令 可 以 用 来 操作 API 对 象 的 Label， 包 括 增加 、 修 改 和 
删除 。 


给 API 对 象 增加 Label， 多 个 Label 之 间 用 空格 分 隔 : 
$ kubectl label TYPE NAME labeli=valuei label2=value2 
HH HAPIY AOA Label, ji ZH_k--overwrite BHT BE m: 


$ kubectl label TYPE NAME labeli=new-value --overwrite 


删除 API 对 象 已 有 的 Label， 在 Label 的 KEY 后 面 加 上 -: 


$ kubectl label TYPE NAME label1- 
另外 ，kubectl label 也 文 持 通过 参数 --all 和 --selector 进 行 批 量 操作 。 
kubectl annotate 


kubectl ”annotate 命 令 可 以 用 来 操作 API 对 象 的 Annotation，kubectl 
annotate 同 kubectl label 命 令 差 不 多 ， 只 不 过 操作 的 对 象 换 成 Annotation。 


给 API 对 象 增加 Annotation: 


$ kubectl annotate TYPE NAME annotation1=value1 annotation2=value 


更 新 API 对 象 已 有 的 Annotation， 需 要 加 上 --overwrite 参 数 进行 履 


Æ, 
ML.» 
$ kubectl annotate TYPE NAME annotationi=new-value --overwrite 


删除 API 对 象 已 有 的 Annotation， 在 Annotation 的 KEY 后 面 加 上 -: 


$ kubectl annotate TYPE NAME annotation1- 


8.3.4 Pod 操 作 


kubectl logs 


kubectl logs 命 令 用 于 打印 Pod 中 容器 的 日 志 输 出 ， 如 果 Pod 只 有 一 个 
容器 ， 不 需要 指定 容器 : 


$ kubectl logs mypod 


而 当 Pod 有 多 个 容 右 的 时 候 ， 需 要 指定 容 右 : 


$ kubectl logs mypod container 


kubectl logs 默 认 会 打印 所 有 日 志 ，--limit-bytes 参 数 可 以 限定 日 志 打 
印 量 ， 而 通过 --tail 参 数 可 以 只 打印 最 新 的 指定 行 数 的 日 志 ， 或 者 通过 -- 
since 和 --since-time 打 印 指定 时 间 的 日 志 。 另 外 ， 通 过 设置 --follow 参 数 ， 
将 实时 打印 日 志 流 ， 达 到 tail -f 的 效果 。 


kubectl attach 


kubectl attach 命 令 用 于 连接 到 Pod 中 启动 的 容器 ， 类 似 于 docker 
attach， 如 果 不 指 定 容 器 ， 则 选择 Pod 的 第 一 个 容器 : 


$ kubectl attach mypod 
也 可 以 指定 容器 : 
$ kubectl attch mypod container 


kubectl exec 


kubectl exec 命 令 用 于 在 Pod 的 容器 中 执行 命令 ， 类 似 于 docker 
exec， 如 果 不 指定 容器 ， 则 选择 Pod 的 第 一 个 容器 : 


$ kubectl exec mypod -- date 
当然 可 以 指定 容器 执行 


$ kubectl exec mypod container -- date 


提示 


kubectl exec 命 令 需 要 在 Kubernetes Node 上 安装 nsenter。 





kubectl port-forward 


kubectl port-forward 命 令 可 以 为 Pod 设 置 端口 转发 ， 通 过 在 本 机 监听 
指定 端口 ， 访 问 这 些 端口 的 请 求 将 会 被 转发 到 Pod 的 容器 中 对 应 的 端口 
ale 


执行 kubectl port-forward 命 令 的 时 候 需 要 指定 Pod 和 端口 转发 规则 ， 
比如 80 端 口 转发 80 端 口 ，443 端 口 转发 443 端 口 : 


$ kubectl port-forward mypod 80:80 443:443 


提示 


kubectl port-forward 命 令 需 要 在 Kubernetes Node 上 安装 nsenter 和 


SOCat。 





8.3.5 Replication Controller 操 作 


kubectl run 


kubectl run 命令 可 以 用 来 创建 Replication Controller， 创 建 的 时 候 必 


ATS KEE as BUR 
$ kubectl run nginx --image nginx 


创建 的 Replication Controller 的 Pod 副 本 数 是 1， 可 以 通过 --replicas 参 
数 设置 Pod 的 副本 数 为 2: 


$ kubectl run nginx --image nginx --replicas 2 


默认 情况 下 ， 创 建 出 来 的 Replication ”Controller 会 为 Pod 设 置 一 个 
Label，Label 的 Key 为 run，Value 为 Replication ”Controller 的 名 称 。 如 果 
kubectl run 命 令 中 设置 了 --labels 参 数 ， 则 会 覆盖 这 个 Label。 


kubectl run 命令 中 只 可 以 设置 一 个 容器 ， 文 持 容器 的 属性 设置 如 下 
所 示 。 


。--command: 容器 的 启动 命令 。 

e --port: 容 絮 内 部 的 端口 。 

e --hostport: 容 露 映射 到 宿主 机 的 端口 。 
。--enV: 容 吉 的 环境 变量 。 

。--requests: 容器 的 资源 请 求 规 格 。 

e --limits: 容器 的 资源 限制 规格 。 
kubectl scale 


kubectl scale 命 令 可 以 用 来 修改 Replication Controller 的 Pod 副 本 数 ， 


即 实现 Pod 的 弹性 伸缩 。 执 行 的 时 候 需 要 指定 Replication Controller 和 Pod 
副本 数 : 


$ kubectl scale replicationcontroller nginx --replicas=3 


kubectl scale 命 令 如 果 设 置 了 --current-replicas 参 数 ， 那 么 会 验证 当前 
Pod 的 副本 数 是 否 等 于 --current-replicas 配 置 的 数目 ， 相 等 才 进 行 修改 操 
(Es 


kubectl autoscale 


kubectl autoscale 命 令 可 以 为 Replication Controller 创 建 Horizontal Pod 
Autoscaler， 即 实现 Pod 的 自动 伸缩 。 执 行 的 时 候 需 要 指定 Replication 
Controller， 以 及 Pod 的 最 大 和 最 小 副本 数 : 


$ kubectl autoscale replicationcontroller nginx --min=1 --max=10 


8.3.6 ”Service 探 作 


kubectl expose 


kubectl expose 命 令 可 以 用 来 创建 Service， 创 建 的 时 候 需 要 指定 
Pod、Replication Controller 或 者 Service， 从 中 提取 Label 来 为 新 建 的 
Service 配 置 Label Selector: 


$ kubectl expose pod valid-pod --port=444 --name=frontend 
$ kubectl expose replicationcontroller nginx --port=80 --target-p 


$ kubectl expose service nginx --port=443 --target-port=8443 --na 
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第 9 章 
Kubernetes 网 络 





Kubernetes 从 Docker 默 认 的 网 络 模型 中 独立 出 来 形成 一 套 上 自己 的 网 
络 模型 ， 访 网络 模型 更 加 适应 传统 的 网 络 模式 ， 应 用 能 够 平滑 地 从 非 容 
器 环境 迁移 到 同 Kubernetes 中 。 本 章 将 对 比 说 明 Kubernetes 和 Docker 的 网 
络 模型 ， 然 后 详细 讲解 Kubernetes 网 络 模型 的 实现 细节 。 





9.1 Docker) 24 he 


Docker 使 用 Linux 桥 接 ， 在 答 主 机 上 虚拟 一 个 Docker 网 桥 
Cdocker0) ，Docker 启 动 一 个 容器 时 会 根据 Docker 网 桥 的 网 段 分 配 容器 
的 PP， 同 时 Docker 网 桥 是 每 个 容器 的 默认 网 关 。 因 为 在 同一 宿主 机 内 的 
容器 都 接 入 同一 个 网 桥 ， 这 样 容器 之 间 就 能 通过 容器 的 卫 直 接 通信 ， 如 
图 9-1 所 示 。 
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图 9-1 Docker H %& 





Docker 网 桥 是 宿主 机 虚拟 出 来 的 ， 并 不 是 真实 存在 的 网 络 设备 ， 外 
部 网 络 是 无 法 寻 址 到 的 ， 这 也 意味 着 外 部 网 络 无 法 直接 访问 到 容器 。 如 
果 容 右 锅 望 能 够 被 外 部 网 络 访问 到 ， 束 需要 通过 映射 容器 并 口 到 宿主 机 
《端口 映射 ) ， 即 使 用 docker run 创 建 容器 时 通过 -p 或 -P 参 数 来 启用 ， 访 
问 容器 的 时 候 通 过 [和 窒 主 机 IP]:[ 容 器 端口 ] 访 问 容器 。 











实际 上 上， 端口 映射 通过 在 iptables 的 NAT 表 中 添加 相应 的 规则 ， 所 以 
我 们 也 将 端口 映射 方式 称 为 NAT 方 式 。 在 早期 组 建 Docker 机 融 集 群 的 方 
案 中 ， 往 往 是 选择 了 NAT 方 式 的 网 络 模型 。 这 种 网 络 模型 对 使 用 的 便利 
性 是 有 意义 的 ， 但 并 不 理想 。 这 个 模型 需要 对 各 种 端口 进行 映射 ， 这 会 
限制 宿主 机 的 能 力 ， 在 容 圳 编排 上 也 增加 了 复杂 上 度 。 





端口 是 个 稀缺 资源 ， 这 就 需要 解决 端口 冲突 和 动态 分 配 端 口 问 


题 。 这 不 但 使 调度 复杂 化 ， 而 且 应 用 程序 的 配置 也 将 变 得 复杂 ， 具 体 表 
现 为 端口 冲突 、 重 用 和 耗 尽 。 





。 NATI 将 地 址 空间 分 段 的 做 法 引入 了 额外 的 复杂 上 度 。 比 如 容器 中 应 
用 所 见 的 P 并 不 是 对 外 其 圳 的 PP， 因为 网 络 隔 离 ， 容 器 中 的 应 用 实际 上 
只 能 检测 到 容器 的 IP， 但 是 需要 对 外 宣称 的 则 是 宿主 机 的 PP， 这 种 信息 
的 不 对 称 将 带 来 诸如 破坏 目 注 册 机 制 等 问题 。 











9.2 Kubernetes 2% te HY 


Kubernetes 从 Docker 网 络 模型 (NAT 方 式 的 网 络 模型 ) 中 独立 出 来 
形成 一 套 新 的 网 络 模 型 。 该 网 络 模型 的 目标 是 : 每 一 个 Pod 都 拥有 一 个 
扁平 化 共享 网 络 命名 空间 的 卫 ， 称 为 PodIP。 通 过 PodIP，Pod 能 够 跨 网 
络 与 其 他 物理 机 和 Pod 进 行 通信 。 一 个 Pod 一 个 下 的 〈IP-Per-Pod) 模型 
创建 了 一 个 干净 、 反 问 兼 容 的 模型 。 在 该 模型 中 ， 从 端口 分 配 、 网 络 、 
域名 解析 、 服 务 发 现 、 负 载 均衡 、 应 用 配置 和 迁移 等 角度 ，Pod 都 能 够 
被 看 成 虚拟 机 或 物理 机 ， 这 样 应 用 就 能 够 平滑 地 从 非 容器 环境 (物理 机 
或 虚拟 机 ) 迁移 到 同一 个 Pod 内 的 容器 环境 。 


为 了 实现 这 个 网 络 模型 ， 在 Kubernetes 中 需要 解决 几 个 问题 : 
。 容 器 间 通 信 (Container to Container) 
。Pod 间 通信 (Pod to Pod) 


。Service 到 Pod 的 通信 (Service to Pod) 


9.3 Ass las 


Pod 是 容器 的 集合 ，Pod 包 含 的 容器 都 运行 在 同一 个 宿主 机 上 ， 这 些 
容器 将 拥有 同样 的 网 络 空间 ， 容 器 之 间 能 够 互相 通信 ， 它 们 能 够 在 本 地 
访问 其 他 容器 的 端口 。 





现在 创建 一 个 Web Pod， 包 含 两 个 容器 : 容器 Webpod80 将 局 动 监 昕 
80 端 口 的 Web 服 务 ， 容 器 webpod8080 将 启动 监听 8080 端 口 的 Web 服 务 ， 
同时 配置 了 端口 映射 规则 。Web Pod 的 定义 文件 web-pod.yaml: 


apiVersion: v1 
kind: Pod 
metadata: 
name: webpod 
labels: 
name: webpod 
spec: 
containers: 
- name: webpod80 
image: jonlangemak/docker :web_container_80 
ports: 
- containerPort: 80 
hostPort: 80 
- name: webpod8080 
image: jonlangemak/docker :web_container_8080 
ports: 


- containerPort: 8080 


hostPort: 8080 


Web Pod 运 行 成 功 后 ， 在 其 所 在 的 Node 上 得 询 容 堪 : 


$ docker ps 

CONTAINER ID IMAGE PORTS 
63dc7e032ab6 jonlangemak/docker :web_container_8080 
4acia5156a04 jonlangemak/docker :web_container_80 


b77896498f8f gcr.io/google_containers/pause:0.8.0 0.0.0.0:80- 


可 以 看 到 运行 了 3 个 容器 ， 其 中 前 两 个 容器 是 在 Web Pod 定 义 中 指定 
的 ， 可 以 称 为 业务 容器 。 第 3 个 运行 的 容器 镜像 是 
gcr.io/google_containers/pause:0.8.0, Web Pod 定 义 中 设置 的 业务 容器 的 
端口 映射 规则 都 集中 配置 在 了 网 络 容 右 上 ， 实 际 上 它 是 Kubernetes 中 定 
义 的 网 络 容器 ， 它 不 做 任何 事情 ， 只 是 用 来 接管 Pod 的 网 络 ， 业 务 容器 
通过 加 入 网 络 容 器 的 网 络 实现 网 络 共享 。 





那么 为 什么 要 使 用 额外 的 网 络 容器 ， 而 不 是 以 Pod 的 第 一 个 容器 作 
为 网 络 容器 呢 ? 主要 是 为 了 避免 业务 容 圳 之 间 产 生 依赖 ， 比 如 第 二 个 容 
融 连 接 到 第 一 个 容器 ， 当 第 一 个 容 露 宕 机 时 ， 那 么 第 二 个 容器 的 网 络 栈 
也 会 失效 。 


网 络 容器 镜像 可 以 通过 Kubelet 的 启动 参数 --pod-infra-container- 
image 指 定 ， 不 同 版 本 下 使 用 的 默认 镜像 不 一 样 ， 当 前 版 本 (Kubernetes 
v1.1.1) 默认 是 gcr.io/google_containers/”pause:0.8.0， 这 是 一 个 非常 小 的 
镜像 ， 启 动容 器 后 只 会 运行 一 个 叫 作 pause 的 程序 ， 顾 名 思 义 ，pause 的 
作用 只 是 暂停 ， 防 止 容器 退出 。 


实际 上 ，Kubernetes 利 用 了 Docker 的 容器 网 络 共 享 能 力 ，Web Pod 中 


的 容 右 类 似 于 使 用 以 下 命令 运行 ， 而 Pod 的 PodIP 便 是 网 络 容 器 的 IP: 


$ docker run -p 80:80 -p 8080:8080 --name network-container -d gc 
$ docker run --net container:network-container -d jonlangemak/doc 


$ docker run --net container:network-container -d jonlangemak/doc 


这 样 一 来 ，Pod 中 的 所 有 容器 都 是 互通 的 ， 而 Pod 对 外 可 以 看 成 一 个 
完整 网 络 单元 ， 如 图 9-2 所 示 。 





图 9-2 Pod 中 的 容器 网 络 


9.4 Pod 间 通信 


Kubernetes 网 络 模型 是 一 个 局 平 化 的 网 络 平面 ， 在 这 个 网 络 平面 


内 ，Pod 作 为 一 个 网 络 单元 同 Kubernetes Node 的 网 络 处 于 同一 层级 。 


我 们 考虑 一 个 最 小 的 Kubernetes 网 络 拓扑 ， 如 图 9-3 所 示 ， 在 这 个 网 
络 拓扑 中 满足 以 下 条 件 。 
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图 9-3 Kubernetes 网 络 拓扑 


Pod 则 通信 : Pod1 和 Pod2 〈 同 主机 ) ，Pod1 和 Pod3 (CENL 能 
人 够 通信 。 


。Node 与 Pod 间 通信 : Nodel 和 Pod1/ Pod2 〈 同 主机 ) , Pod3 (HSE 
机 ) 能 够 通信 。 


那么 第 一 个 问题 是 如 何 保 证 Pod 的 PodIP 是 全 局 唯一 的 。 其 实 做 法 也 
很 简单 ， 因 为 Pod 的 PodIP 是 Docker 网 桥 分 配 的 ， 所 以 将 不 同 Kubernetes 
Node 的 Docker 网 桥 配 置 成 不 同 的 IP 网 段 即 可 。 





另外 ， 同 一 个 Kubernetes Node 上 的 Pod/ 容 器 原生 能 通信 ， 但 是 
Kubernetes Node 之 间 的 Pod/ 容 器 是 如 何 通 信 的 ， 这 就 需要 对 Docker 进 行 
增强 ， 在 容器 集群 中 创建 一 个 履 盖 网 络 〈Overlay Network) ， 联 通 各 个 


节点 ， 目 前 可 以 通过 第 三 方 网 络 插件 来 创建 覆 兰 网络， 比如 Flannel 和 


Open vSwitch 等 。 


9.4.1 FlannelS< | Kubernetes7s 3 2 
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集群 中 创建 一 个 履 盖 网 络 ， 为 主机 设 定 一 个 子 网 ， 通 过 隧道 协议 封装 容 
器 之 间 的 通信 报 文 ， 实 现 容器 的 路 主机 通信 。 


现在 我 们 利用 Flannel 联 通 两 个 Kubernetes Node， 如 表 9-1 所 示 。 


表 9-1 Kubernetes Node 信 息 





节点 主机 名 IP 
Kubernetes Node 1 kube-node-1 192.168.3.147 
Kubernetes Node 2 kube-node-2 192.168.3.148 


Flannel 使 用 Etcd 作 为 配置 和 协调 中 心 ， 在 运行 Flannel 之 前 需要 在 
Etcd 中 进行 配置 。Flannel 的 Etcd 配 置 目录 可 以 通过 启动 参数 -etcd-prefix 


指定 ， 默 认 是 /coreos.com/network。 


首先 需要 在 Etcd 上 配置 Flannel 网 络 信 息 : 


$ etcdctl set /coreos.com/network/config '{ "Network": "10.0.0.0/ 


配置 完成 后 ， 在 Kubernetes Node 上 运行 Flannel，Flannel 在 初次 启动 
的 时 候 会 检查 Etcd 中 的 配置 ， 然 后 为 当前 节点 分 配 可 用 的 IP 网 段 ， 然 后 


在 Etcd 中 创建 一 个 路 由 表 ， 通 过 Etcd 查 询 路 由 表 : 


$ etcdctl ls /coreos.com/network/subnets 
/coreos.com/network/subnets/10.0.10.0-24 


/coreos.com/network/subnets/10.0.62.0-24 


$ etcdctl get /coreos.com/network/subnets/10.0.62.0-24 
{"PublicIP":"192.168.3.147"} 


$ etcdctl get /coreos.com/network/subnets/10.0.10.0-24 
{"PublicIP":"192.168.3.148"} 


Flannel ”在 分 配 到 IP 网 段 之 后 ， 会 创建 一 个 虚拟 网 卡 ， 在 
Kubernetes Node 1 上 查询 Flannel 虚 拟 网 卡 : 


$ ip addr show flannel.1 
5: flannel.1: <BROADCAST, MULTICAST, UP, LOWER_UP> mtu 1450 qdisc 
link/ether 62:71:56:28:bd:dd brd ff: ff: ff: ff: ff: ff 
inet 10.0.62.0/16 scope global flannel.1 
valid_lft forever preferred_lft forever 
inet6 fe80: :6071:56ff:fe28:bddd/64 scope link 


valid_lft forever preferred_lft forever 


另外 ，EFlannel 会 配置 Docker 网 桥 〈docker0) ， 实 际 上 就 是 通过 修改 
Docker 的 启动 参数 --bip 来 实现 。 这 样 一 来 ， 集 群 中 每 个 节点 的 Docker 网 
桥 就 分 配 好 了 全 局 唯一 的 卫 网 段 ， 从 而 创建 出 来 的 容器 也 将 拥有 全 局 唯 
一 的 PP， 比如 在 Kubernetes Node 1 上 查询 Docker 网 桥 : 


$ ip addr show dockero 
6: dockerO: <NO-CARRIER, BROADCAST, MULTICAST, UP> mtu 1450 qdisc 
link/ether 56:84:7a:fe:97:99 brd ff: ff: ff: fF: ff: ff 
inet 10.0.62.1/24 scope global dockerg 
valid_lft forever preferred_lft forever 
inet6 fe80: :5484: 7aff:fefe:9799/64 scope link 


valid_lft forever preferred_lft forever 


由 此 ，Flannel 为 两 个 Kubernetes Node 划 分 好 了 容器 网 络 网 段 ， 如 表 
9-2FITAN - 


#9-2 Kubernetes Node 容 器 网 络 网 段 划 分 (Flannel) 


ae 主机 名 IP Docker 网 桥 


Kubernetes 
Node 1 


Kubernetes kube-node-2 192.168.3.148 
Node 2 


除 此 之 外 ，Flannel 会 修改 路 由 表 ， 使 得 Flannel 虚 拟 网 卡 可 以 接管 容 
器 跨 主 机 的 通信 。 在 Kubernetes Node 1 上 查询 路 由 表 : 













kube-node-1 192.168.3.147 10.0.62.1/24 


10.0.10.1/24 





$ route -n 

Kernel IP routing table 

Destination Gateway Genmask Flags Metric 
10.0.0.0 0.0.0.0 255.255.0.0 U 0 
10.0.62.0 0.0.0.0 255.255.255.0 U 0 


在 Kubernetes Node 2 上 查询 路 由 表 : 


$ route -n 


Kernel IP routing table 


Destination Gateway Genmask Flags Metric R 
10.0.0.0 0.0.0.0 255.255.0.0 U 0 
10.0.10.0 0.0.0.0 255.255.255.0 U 0 


这 样 一 来 ， 当 一 个 节点 的 容器 访问 另 一 个 节点 的 容器 时 ， 源 节点 上 
的 数据 会 从 docker0 网 桥 路 由 到 flannel1.1 网 卡 ， 在 目的 节点 会 从 flannel 
1.1 网 卡 路 由 到 docker0 网 桥 。 比 如 现在 有 一 个 数据 包 要 从 IP 为 10.0.62.2 的 
容 右 发 到 IP 为 10.0.10.2 的 容器 ， 根 据 Kubernetes Node 1 的 路 由 表 ， 它 只 
与 10.0.0.0/16 这 条 记录 匹配 ， 因 此 数据 包 从 docker0 网 桥 出 来 以 后 就 被 路 
由 到 了 flannel1.1 网 卡 。 同 理 ， 在 Kubernetes Node 2 上 ， 由 于 目的 地 址 匹 
配 在 docker0 网 桥 对 于 的 10.0.10.0/24 这 个 记录 上 ， 数 据 包 从 flannel1.1 网 
卡 出 来 以 后 就 被 路 由 到 了 docker0 网 桥 ， 最 后 转发 给 目标 容器 。 





Flannel 虚 拟 网 卡 接收 到 的 数据 包 会 被 Flannel 服 务 进行 封装 ，PFlannel 
将 通过 隧道 协议 封装 这 些 数据 包 ， 目 前 隧道 协议 已 经 文 持 UDP、 
VxLAN 等 ， 默 认 是 UDP。 当 容器 器 主 机 通信 的 时 候 ， 源 主机 的 Flannel 
服务 将 接收 到 的 数据 包 包装 在 另 一 种 网 络 包 中 ， 然 后 目的 主机 的 Flannel 
服务 再 进行 解 包 。 


最 终 ，Flannel 将 运行 在 所 有 Kubernetes Node 上 ，Flannel 重 新 规划 容 
器 集群 网 络 ， 从 而 使 得 集群 中 所 有 容器 能 够 获得 同属 一 个 内 网 且 不 重复 
的 IP， 并 让 属于 不 同 节点 上 的 容器 能 够 直接 通过 内 网 JP 通信 ，Flannel 实 
现 的 网 络 结构 如 图 9-4 所 示 。 
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图 9-4 Flannel &#UKubernetes#% ž I 2% 


9.4.2 ”使 用 Open vSwitch 实 现 Kubernetes 
履 盖 网 络 





Open vSwitch 是 一 个 高 质量 的 、 多 层 虚 拟 交 换 机 ， 使 用 开源 Apache 
2.0 许 可 协议 ， 由 Nicira Networks 开 发 。 它 的 目的 是 让 大 规模 网 络 目 动 化 
可 以 通过 编程 扩展 ， 同 时 仍然 支持 标准 的 管理 接口 和 协议 。 





Open VvSwitch 也 提供 了 对 OpenFlow 协 议 的 支持 ， 用 户 可 以 使 用 任何 
支持 OpenFlow 协 议 的 控制 器 对 Open vSwitch 进 行 远 程 管 理 控 制 。Open 
VvSwitch 是 一 项 非常 重要 的 SDN 技 术 ， 可 以 灵活 地 创建 出 满足 各 种 需求 
的 虚拟 网 络 ， 也 包括 Kubernetes 中 的 履 盖 网 络 。 





现在 我 们 利用 Open vSwitch 联 通 两 个 Kubernetes Node。 为 了 保证 容 
器 IP 不 冲突 ， 所 以 必须 规划 好 Kubernetes Node 上 Docker 网 桥 的 网 段 ， 如 
表 9-3 所 示 。 


表 9-3 Kubernetes Node 容 器 网 络 网 段 划 分 (Open vSwitch) 





ae 主机 名 IP Docker 网 桥 


one kube-node-1 192.168.3.147 | 10.246.0.1/24 
Node 1 





Kubernetes kube-node-2 192.168.3.148 | 10.246.1.1/24 
Node 2 


Open vSwitch 实 现 的 网 络 模型 如 图 9-5 所 示 。 
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图 9-5 Open vSwitch 实 现 Kubernetes 履 盖 网 络 


1. 首先 设置 Docker 网 桥 : 
e Kubernetes Node 1 


$ brctl addbr dockerg 
$ ip link set dev dockerO up 
$ ifconfig dockerO 10.246.0.1 netmask 255.255.255.0 up 


。 Kubernetes Node 2 


$ brctl addbr dockerO 
$ ip link set dev dockerO up 
$ ifconfig dockerO 10.246.1.1 netmask 255.255.255.0 up 


2. 然后 创建 Open vSwitch 虚 拟 网 桥 obr0， 连 接 各 个 网 络 设备 : 


e Kubernetes Node 1 





# 创 建 obrg 
$ ovs-vsctl add-br obrO -- set Bridge obrg fail-mode=secure 


$ ovs-vsctl set bridge obr0 protocols=OpenFlow13 





# 创 建 GRE 隧 道 
$ ovs-vsctl add-port obro gre0 \ 


-- set Interface greO type=gre options:remote_ip=flow options: key 





# 创 建 tun0 连 接 docker0 和 obrg 
$ ovs-vsctl add-port obrO tung0 -- set Interface tunO type=interna 
$ brctl addif dockerO tung 


$ ip link set tunO® up 


# 设 置 0penFLow 规 则 

$ ovs-ofctl -0 OpenFlowi3 del-flows obro 

$ ovs-ofctl -0 OpenFlow13 add-flow obr0 \ 

table=0, ip, in_port=10, nw_dst=10.246.0.1/24, actions=output :9 


$ ovs-ofctl -0 OpenFlow13 add-flow obrO \ 


table=0, arp, in_port=10, nw_dst=10.246.0.1/24, actions=output:9 

$ ovs-ofctl -0 OpenFlow13 add-flow obrO® \ 

table=0, in_port=9, ip, nw_dst=10.246.1.1/24, actions=set_field:192.1 
$ ovs-ofctl -0 OpenFlow13 add-flow obrO \ 


table=0, in_port=9, arp, nw_dst=10.246.1.1/24, actions=set_field:192. 


e Kubernetes Node 2 





# 创 建 obrg 
$ ovs-vsctl add-br obrO -- set Bridge obrg fail-mode=secure 


$ ovs-vsctl set bridge obr0 protocols=OpenFlow13 





# 创 建 GRE 隧 道 
$ ovs-vsctl add-port obrg greO \ 


-- set Interface greO type=gre options:remote_ip=flow options: key 





# 创 建 tun0 连 接 docker0 和 obrg 





$ ovs-vsctl add-port obro tunO -- set Interface tunO type=interna 
$ brctl addif dockerO tuno 


$ ip link set tun® up 


# 设 置 0penFLow 规 则 

$ ovs-ofctl -0 OpenFlow13 del-flows obro 

$ ovs-ofctl -0 OpenFlowi3 add-flow obrO \ 

table=0, ip, in_port=10, nw_dst=10.246.1.1/24, actions=output:9 
$ ovs-ofctl -0 OpenFlowi3 add-flow obrO \ 


table=0, arp, in_port=10, nw_dst=10.246.1.1/24, actions=output:9 


$ ovs-ofctl -0 OpenFlow13 add-flow obrO® \ 
table=0, in_port=9, ip, nw_dst=10.246.0.1/24, actions=set_field:192.1 
$ ovs-ofctl -0 OpenFlow13 add-flow obro \ 
table=0, in_port=9, arp, nw_dst=10.246.0.1/24, actions=set_field:192. 


output:10 


3. 最 后 配置 路 由 : 
e Kubernetes Node 1 

$ ip route add 10.246.0.0/16 dev docker® scope link src 10.246.0. 
e Kubernetes Node 2 


$ ip route add 10.246.0.0/16 dev docker® scope link src 10.246.1. 


9.5 ”Service 到 Pod 通 信 


Service 在 Pod 之 间 起 到 服务 代理 的 作用 ， 对 外 表现 为 一 个 单一 访问 
接口 ， 将 请 求 转 发 给 Pod，Service 的 网 络 转发 是 Kubernetes 实 现 服务 编排 
的 关键 一 环 。 


现在 有 一 个 Service， 查 询 详情 如 下 : 


$ kubectl describe service myservice 
Name: myservice 
Namespace: default 


Labels: <none> 


Selector: name=mypod 

Type: ClusterIP 

IP: 10.254.206.148 

Port: http 80/TCP 

Endpoints: 10.0.62.87:80,10.0.62.88:80,10.0.62.89:80 
Session Affinity: None 


No events. 


可 以 看 到 ， 该 Service 的 虚拟 IP 是 10.254.206.148， 端 口 80/TCP 对 应 
的 Endpoints 包 含 3 个 后 端 10.0.62.87:80、10.0.62.88:80 和 10.0.62.89:80， 
即 当 请 求 10.254.149.17:80 时 ， 会 转发 到 这 些 后 端 之 一 。 


首先 虚拟 IP 是 由 Kubernetes 创 建 的 ， 虚 拟 IP 的 网 段 是 通过 Kubernetes 
API Server 的 启动 参数 --service-cluster-ip-range=10.254.0.0/16 配 置 的 。 


另 一 个 关键 组 件 是 Kubernetes Proxy, Kubernetes Proxy 组 件 负责 实 
现 虚 拟 IP 路 由 和 转 友 ， 而 在 容器 上 履 盖 网 络 之 上 又 实现 了 Kubernetes 层 级 
的 虚拟 转发 网 络 。Kubernetes Proxy 需 要 满足 以 下 功能 : 





。 转 发 访问 Service 的 虚拟 IP 的 请 求 到 Endpoints。 
“监控 Service 和 Endpoints 的 变化 ， 实 时 刷新 转发 规则 。 
© 提供 负 载 均衡 能 


在 当前 版 本 (Kubernetes v1.1.1) F, Kubernetes Proxy 有 两 种 实现 
机 制 : Userspace 和 Iptables， 可 以 通过 Kubernetes Proxy 的 启动 参数 -- 
proxy-mode 指 定 。 


9.5.1 Userspace# rk 


在 Userspace 模 式 下 ，Kubernetes “Proxy 将 会 为 每 一 个 Service 在 主机 
上 启用 随机 端口 进行 监 旷 ， 并 且 创 建 Iptables 规 则 重 定 同 访问 Service 虚 拟 
IP 的 请 求 到 这 个 端口 上 ， 而 Kubernetes Proxy 将 请 求 转发 到 Endpoints。 在 
此 模式 下 ，Kubernetes Proxy 起 到 反 辣 代理 的 作用 ， 请 求 的 转发 由 
Kubernetes Proxy 在 用 户 空间 下 完成 。Kubemetes Proxy 需 要 监控 
Endpoints 的 变化 ， 实 时 刷新 转发 规则 ， 如 图 9-6 所 示 。 
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图 9-6 Kubernetes Proxy 的 Userspace 模 式 


当前 Kubernetes Proxy 只 是 3 层 (TCP/UDP Over IP) 转发 ， 默 认 的 负 
载 均衡 策略 是 轮 询 方式 。 


通过 iptables-save 命 令 可 查询 关于 Service myservice 的 Iptables 规 则 : 


$ iptables-save|grep myservice 
-A KUBE-PORTALS-CONTAINER -d 10.254.206.148/32 -p tcp -m comment 
"default/myservice:http" -m tcp --dport 80 -j REDIRECT --to-ports 


-A KUBE-PORTALS-HOST -d 10.254.206.148/32 -p tcp -m comment --com 


"default/myservice:http" -m tcp --dport 80 -j DNAT --to-destinati 


Kubernetes ”Proxy 会 为 Service 创 建 两 条 Iptables 规 则 ， 其 中 包含 如 下 
两 个 Iptables 自 定义 链 。 


e KUBE-PORTALS-CONTAINER: 用 于 [匹配 容器 发 出 的 报 文 ， 绑 
定 在 NAT 表 PREROUTING 链 。 


e KUBE-PORTALS-HOST: 用 于 匹配 和 窒 主机 发 出 的 报 文 ， 绑 定 在 
NAT 表 OUTPUT 链 。 





对 于 Service myservice， 两 条 Iptables 规 则 的 作用 都 是 为 了 将 目的 IP 
为 10.254.206.148/32， 并 且 目 的 端口 为 80 的 报 文 重 定向 到 本 机 的 35841 端 
口 ， 而 35841 端 口 束 是 Kubernetes Proxy 监 听 的 端口 ，Kubernetes Proxy 监 
昕 在 35841， 作 为 反 加 代理 将 请 求 转发 到 Service myservice 的 Endpoints。 





$ lsof -i:35841 
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME 
kube-proxy 1040 root 5u IPv6 20457 oto TCP MaD 


9.5.2 Iptablestix\ 


在 Iptables 模 式 下 ，Kubernetes ”Proxy 则 是 完全 通过 创建 Iptables 规 
则 ， 直 接 重 定 癌 访 问 Service 虚 拟 IP 的 请 求 到 Endpoints。 而 当 Endpoints 发 
生变 化 的 时 候 ，Kubernetes Proxy 会 刷新 相关 的 Iptables 规 则 。 在 此 模式 
F, Kubernetes Proxy 只 是 负责 监控 Service 和 Endpoints， 更 新 Iptables 规 


则 ， 报 文 的 转发 依赖 于 Linux 内 核 ， 默 认 的 负载 均衡 策略 是 随机 方式 ， 


如 图 9-7 所 示 。 





Node 





Service VIP ae) | aaae 
10.254.206.148 
Iptables 



































图 9-7 Kubernetes Proxy 的 1ptables 模 式 


通过 iptables-save 命 令 可 查询 到 关于 Service ”myservice 的 Iptables 规 


则 : 


$ iptables-save|grep myservice 

-A KUBE-SEP-5534AF2Y644GLPZI -s 10.0.62.87/32 -m comment 
http" -j MARK --set-xmark 0x4d415351/0xf Ff FT FFF 

-A KUBE-SEP-5534AF2Y644GLPZI -p tcp -m comment --comment 
-j DNAT --to-destination 10.0.62.87:80 

-A KUBE-SEP-5UWZC74U4HN6VNI5 -s 10.0.62.88/32 -m comment 
http" -j MARK --set-xmark 0x4d415351/0xf Ff FTF FFF 

-A KUBE-SEP-5UWZC74U4HN6VNI5 -p tcp -m comment --comment 
-j DNAT --to-destination 10.0.62.88:80 

-A KUBE-SEP-W2TMLVNCN2RGF2MT -s 10.0.62.89/32 -m comment 
http" -j MARK --set-xmark 0x4d415351/0xf Ff FTF FFF 


- -Commen 


"default 


- -Commen 


"default 


- -Commen 


-A KUBE-SEP-W2TMLVNCN2RGF2MT -p tcp -m comment --comment "default 
-j DNAT --to-destination 10.0.62.89:80 

-A KUBE-SERVICES -d 10.254.206.148/32 -p tcp -m comment --comment 
cluster IP" -m tcp --dport 80 -j MARK --set-xmark 0x4d415351/0xfF 
-A KUBE-SERVICES -d 10.254.206.148/32 -p tcp -m comment --comment 
cluster IP" -m tcp --dport 80 -j KUBE-SVC-YZPZUSJVGCLDKDHP 

-A KUBE-SVC-YZPZUSJVGCLDKDHP -m comment --comment "default/myserv 
--mode random --probability 0.33332999982 -j KUBE-SEP-5534AF2Y644 
-A KUBE-SVC-YZPZUSJVGCLDKDHP -m comment --comment "default/myserv 
--mode random --probability 0.50000000000 -j KUBE-SEP-5UWZC74U4HN 
-A KUBE-SVC-YZPZUSJVGCLDKDHP -m comment --comment "default/myserv 


KUBE - SEP-W2TMLVNCN2RGF2MT 


Kubernetes Proxy 会 为 Service 创 建 一 系列 Iptables 规 则 ， 其 中 包含 
Iptables 自 定义 链 。 


e KUBE-SERVICES: 绑 定 在 NAT 表 PREROUTING 链 和 OUTPUT 
链 。 


。KUBE-SVC-*:， 代 表 一 个 Service， 绑 定 在 KUBE-SERVICES。 


。 KUBE-SEP-*: 代表 Endpoints 的 每 一 个 后 端 ， 绑 定 在 KUBE-SVC- 


对 于 Service ”myservice，Service 对 应 的 Iptables 自 定义 链 是 KUBE- 
SVC-YZPZUSJVGC- ”LDKDHP，Endpoints 对 应 的 Iptables 自 定义 链 是 
KUBE-SEP-5534AF2Y644GLPZI、KUBE-SEP- 5UWZC74U4HN6VNI5 和 
KUBE-SEP-W2TMLVNCN2RGF2MT. 


通过 iptables 查 询 可 以 更 加 清晰 地 看 出 转发 的 规则 : 


$ iptables -t nat -L -n 
Chain PREROUTING (policy ACCEPT) 
target prot opt source destination 


KUBE-SERVICES all -- 0.0.0.0/0 0.0.0.0/0 /* kubernete 


Chain INPUT (policy ACCEPT) 


target prot opt source destination 


Chain OUTPUT (policy ACCEPT) 

target prot opt source destination 
KUBE-SERVICES all -- 0.0.0.0/0 ©.0.0.0/0 /* kuberne 
Chain POSTROUTING (policy ACCEPT) 

target prot opt source destination 

MASQUERADE all -- 0.0.0.0/0 0.0.0.0/0 /* kubernete 


requiring SNAT */ mark match 0x4d415351 


Chain KUBE-SERVICES (2 references) 

target prot opt source destination 

MARK tcp -- 0.0.0.0/0 10.254.206.148 /* def 
cluster IP */ tcp dpt:80 MARK set 0x4d415351 
KUBE-SVC-YZPZUSJVGCLDKDHP tcp -- 0.0.0.0/0 10.254 


myservice:http cluster IP */ tcp dpt:80 


Chain KUBE-SVC-YZPZUSJVGCLDKDHP (1 references) 


target prot opt source destination 


KUBE-SEP-5534AF2Y644GLPZI all -- 0.0.0.0/0 0.0.0.0 
myservice:http */ statistic mode random probability 0.33332999982 
KUBE-SEP-5UWZC74U4HN6VNI5 all -- 0.0.0.0/0 0.0.0. 
myservice:http */ statistic mode random probability 0.50000000000 
KUBE-SEP-W2TMLVNCN2RGF2MT all -- 0.0.0.0/0 0.0.0. 


myservice:http */ 


Chain KUBE-SEP-5534AF2Y644GLPZI (1 references) 

target prot opt source destination 

MARK all -- 10.0.62.87 0.0.0.0/0 f* 
MARK set 0x4d415351 

DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 /* 
tcp to:10.0.62.87:80 


Chain KUBE-SEP-5UWZC74U4HN6VNI5 (1 references) 

target prot opt source destination 

MARK all -- 10.0.62.88 0.0.0.0/0 /* d 
MARK set 0x4d415351 

DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 A* 
tcp to:10.0.62.88:80 


Chain KUBE-SEP-W2TMLVNCN2RGF2MT (1 references ) 

target prot opt source destination 

MARK all -- 10.0.62.89 0.0.0.0/0 77 
MARK set 0x4d415351 

DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 A 
tcp to:10.0.62.89:80 


第 10 章 
Kubernetes 安 全 


安全 永远 是 一 个 重大 的 话题 ， 特 别 是 对 于 Kubernetes 这 样 的 云 计算 


平台 ， 


更 需要 设计 出 一 套 完善 的 安全 方案 ， 以 应 对 复杂 的 场景 。 本 章 将 


前 述 Kubernetes 的 安全 保障 机 制 ， 主 要 包括 Kubernetes API 的 安全 访问 、 
容器 安全 和 多 租户 。 


10.1 Kubernetes 安 全 原则 


Kubernetes 设 计 出 了 一 套 API 和 敏感 信息 处 理 方 案 ， 也 提供 了 容器 安 
全 保障 ， 以 下 是 Kubernetes 的 安全 设计 原则 : 


* 保 证 容器 与 其 运行 的 宿主 机 之 间 有 明确 的 隔离 。 


o 限制 容器 对 基础 设施 或 者 其 他 容 需 造成 不 恨 影 啊 。 


。 最 小 特权 原则 一 一 限定 每 个 组 件 只 被 赋予 执行 操作 所 必需 的 最 小 


特权 ， 


由 此 确保 可 能 产生 的 损失 最 小 。 


“普通 用 户 明确 区 别 于 系统 管理 员 。 


© 能 够 给 普通 用 户 赋 予 管理 权限 。 


© 应 用 能 够 安全 地 获取 敏感 信息 。 


10.2 Kubernetes API 的 安全 访问 


Kubernetes API Server 是 Kubernetes 系 统 的 入 口 ， 以 REST API 接 口 方 
式 提 供给 外 部 客户 和 内 部 组 件 调用 ， 对 于 Kubernetes API 的 访问 调用 需 
要 进行 严格 管控 ， 保 证 系统 的 安全 。 


10.2.1 HTTPS 


Kubernetes API Server 采 用 的 是 REST 模 式 的 API 服 务 ，REST 利 用 传 
统 Web 特 点 ， 提 出 了 一 个 既 适 于 客户 端 应 用 又 适 于 服务 端 应 用 的 统一 架 
构 ， 极 大 程度 上 统一 及 简化 了 网 站 架构 设计 。 





REST 的 全 称 是 Representational State _ Transfer， 表 示 表 述 性 状态 传 
递 ， 无 顷 Session， 为 了 安全 ， 每 次 请 求 都 得 带 上 映 份 认证 信息 。REST 
是 基于 HTTP 的 ， 也 是 无 状态 的 ，HTTP 是 明文 传输 的 ， 所 以 建议 所 有 的 
请 求 都 通过 HTTPS 发 送 ， 保 证 对 于 系统 中 的 重要 数据 做 SSL 加 密 传输 ， 
如 证 书 、 账 号 密码 等 。 





Kubernetes API Server 支 持 HTTP 和 HTTPS， 相 关 启 动 参数 如 表 10-1 
PAR o 


#10-1 Kubernetes API Server 的 启动 参数 


参数 说 明 

--insecure-bind-address=127.0.0.1 HTTP (HRA) 绑 定 的 本 机 地 址 ，0.0.0.0 表 示 监 听 本 机 的 所 有 
地 址 ， 默 认 是 127.0.0.1 
--insecure-port=8080 不 安全 端口 ，HTTP (不 安全 ) 绑 定 的 本 机 端口 ， 默 认 是 8080 
--bind-address=0.0.0.0 HTTPS (ZÈ) 绑 定 的 本 机 地 址 ， 默 认 是 0.0.0.0 









































--secure-port=6443 ASG, HTTPS CAE) 绑 定 的 本 机 端口 ， 默 认 是 6443， 当 
为 0 时 ， 不 启动 HTTPS 

-tls-cert-file="" HTTPS 需 要 使 用 的 x509 证 书 ， 和 --tls-private-key-file 对 应 。 

当 -tls-cert-file 和 --tls-private-key-file 都 为 空 的 时 候 ， 会 自动 生成 
自 签 名 证 书 和 私 钥 ， 生 成 目录 /var/run/kubernetes 
--tls-private-key-file="" HTTPS 需 要 的 x509 私 钥 ， 和 --tls-cert- 和 对 应 


















































Kubernetes API Server 开 启 HTTPS 需 要 准备 的 HTTPS 证 书 ， 建 议 从 
权威 CA 机 构 申 请 : 


--tls-cert-file=/path/to/cert 
--tls-private-key-file=/path/to/key 
--Secure-port=6443 


--bind-address=0.0.0.0 


因为 HTTP 是 不 安全 的 ， 所 以 应 该 限制 HTTP 的 访问 ， 比 如 设置 防 
火 墙 规格 、 防 止 不 信任 域 的 访问 ， 其 中 最 简单 的 方法 是 只 允许 本 机 访 
问 : 


--insecure-port=8080 


--insecure-bind-address=127.0.0.1 


10.2.2 认证 与 授权 


Kubernetes API ”Server 卓 前 支持 认证 (Authentication)〉 和 授权 
(Authorization) 机制 进行 安全 访问 控制 。 认 证 和 授权 只 作用 于 
Kubernetes API Server 的 安全 端口 〈--secure-port) ， 非 安全 端口 〈-- 


insecure-port) 不 受 约束 。 


10.2.2.1 认证 


Basic Authentication 





Basic Authentication 是 指 客户 并 在 使 用 HTTP 访 问 受 限 资源 时 ， 必 须 
使 用 用 户 名 和 密码 以 获取 认证 。 这 是 认证 中 最 简单 的 方法 ， 长 期 以 来 ， 
这 种 认证 方法 被 广泛 使 用 。 当 通过 HTTP 访 问 一 个 使 用 Basic 
Authentication 保 护 的 资源 时 ， 服 务 器 通常 会 在 HTTP 请 求 的 响应 中 加 入 
一 个 “401 需 要 里 份 验证 ”的 头 域 ， 来 通知 客户 提供 用 户 任 证， 以 使 用 资 
源 。 如 果 正 在 使 用 浏览 器 访问 需要 认证 的 资源 ， 浏 览 器 会 弹出 一 个 窗 
口 ， 让 你 输入 用 户 名 和 密码 ， 如 果 所 输入 的 用 户 名 在 资源 使 用 者 的 验证 
列表 中 ， 并 且 和 密码 完 全 正确 ， 此 时 ， 用 户 才 可 以 访问 受 限 的 资源 。 但 是 
这 种 方式 安全 性 较 低 ， 束 是 简单 地 将 用 户 名 和 密码 进行 Base64 编 码 放 到 
头 域 中 。 正 是 因为 是 Base64 编 码 存储 ， 最 好 使 用 HTTPS 进 行 加 密 传 输 。 





Kubernetes API Server 开 局 Basic _ Authentication 需要 提供 一 个 CSV 格 
式 的 文件 用 于 设置 用 户 列表 ， 每 行 表示 一 个 用 户 ， 共 3 列 : 密码 、 用 户 
名 和 用 户 ID， 以 下 是 一 个 示例 : 





basic_auth.csv 


admin_passwd, admin, 1 


test_passwd, test, 2 


然后 设置 Kubernetes API Server 的 启动 参数 : 


--basic-auth-file=/path/to/basic_auth.csv 


Token Authentication 


Token 是 一 个 用 户 自 定义 的 任意 字符 串 ， 具 有 随机 性 、 不 可 预测 
性 ， 相 比 于 密码 更 加 安全 ， 一 般 黑 客 或 软件 无 法 猜测 出 来 。Token 
Authentication 实 际 上 同 Basic _ Authentication 类 似 ， 使 用 Token 蔡 换 账 号 密 
码 ， 可 在 一 定 程度 上 提高 安全 性 。 


Kubernetes API Server 支 持 Token Authentication， 同 样 需要 提供 一 个 
CSV 格 式 的 文件 用 于 设置 用 户 列 表 ， 每 行 表示 一 个 用 户 ， 共 3 列 : 
Token、 用 户 名 和 用 户 ID， 以 下 是 一 个 示例 : 





token_auth.csv 


ceG1x8PkwDz0Z5LsOe1DShpCD1j67r0a, admin, 1 
5oEhn1YY6V7J31im3wZX1Tzp8XFXOAHXJ, test, 2 


其 中 Token 是 任意 字符 串 ， 可 以 用 以 下 命令 生成 : 

$ echo $(cat /dev/urandom | base64 | tr -d "=+/" | dd bs=32 count 
然后 设置 Kubernetes API Server 的 启动 参数 : 

--token-auth-file =/path/to/token_auth.csv 


Client Certificate Authentication 


Client Certificate 是 一 种 用 于 证 明 用 户 身 份 的 客户 端 数字 证 书 ， 如 果 
ARS vig JF Ja Client Certificate Authentication， 客 户 端 访问 的 时 候 就 需要 提 
供 Client Certificate- 


Kubernetes API Server 支 持 Client Certificate Authentication, 74 =r 





供 信任 的 客户 端 CA 证 书 ， 然 后 配置 局 动 参数 : 
--client-ca-file=/path/to/ca.crt 
OpenID Authentication 


OpenID 是 一 套 以 用 户 为 中 心 的 分 散 式 里 份 认证 系统 ， 用 户 只 需 注 
册 获 取 OpenID 之 后 ， 就 可 以 凭借 此 OpenID 账 号 在 多 个 系统 之 间 自 由 登 
录 使 用 ， 而 不 需要 在 每 一 个 系统 中 注册 账号 ， 实 现 用 户 认 证 。 





Kubernetes API Server% ¥fOpenID Authentication， 相 关 启 动 参数 如 
下 : 


--oidc-issuer-url=<url> 


--oidc-client -id=<id_token> 


Keystone Authentication 





Keystone 是 OpenStack 框 架 中 负责 管理 吴 份 验证 、 服 务 规 则 和 服务 令 
牌 功能 的 模块 。 用 户 访问 资源 需要 验证 用 户 的 身份 与 权限 ， 服 务 执 行 操 
作 也 需要 进行 权限 检测 ， 这 些 都 可 以 通过 Keystone 来 处 理 。 








Kubernetes API Server 支 持 对 接 Keystone 来 实现 认证 ， 相 关 启 动 参 数 
如 下 : 


--experimental-keystone-url=<AuthURL> 


10.2.2.2 ”授权 


Kubernetes API Server 在 认证 之 后 ， 通 过 授权 (Authorization) 可 进 


一 步 进 行 安 全 访问 控制 。 授 权 可 以 通过 Kubernetes API Server 的 -- 
authorization-mode 局 动 参数 设置 以 下 几 种 模式 : 


e --authorization-mode=AlwaysDeny 
e --authorization-mode=AlwaysAllow 


è --authorization-mode=ABAC 





其 中 AlwaysDeny 表 示 拒 绝 所 有 请 求 ，AlwaysAllow 人 允许 所 有 请 求 。 


ABAC 是 一 种 基于 属性 的 访问 控制 ， 根 据 设置 好 的 访问 集 略 检 查 请 
求 的 属性 ， 不 符合 访问 策略 的 请 求 会 被 拒绝 。 


API 请 求 中 有 5 个 属性 可 以 用 作 访 问 控制 : 


。 用 户 ， 请 求 用 于 认证 的 用 户 ， 比 如 使 用 Basic Authentication}, H 
户 需 要 输入 用 户 名 和 密码 进行 认证 ， 那 么 授权 则 根据 该 用 户 进 行 判 断 。 


。 用 户 组 ， 用 户 所 在 的 用 户 组 ， 一 个 用 户 可 以 在 多 个 用 户 组 内 。 
。 请 求 是 否 只 读 ， 比 如 GET 请 求 都 是 只 读 的 。 


。 请 求 访问 的 资源 ， 比 如 /api/vl/mamespaces/default/pods 请 求 的 资源 
是 pods， 一 些 情况 下 资源 为 空 ， 比 如 /version。 


。 ”资源 所 在 的 Namespace， 某 些 资 源 不 属于 任何 Namespace， 比 如 
Node， 那 么 Namespace 即 为 空 。 


当 设 置 为 ABAC 模 式 时 ， 还 需要 指定 策略 文件 《〈--authorization- 
policy-file) ， 策 略 文件 采用 一 种 One JSON Object Per Line 的 配置 格式 ， 


即 每 一 行 是 一 个 JSON 格 式 的 策略 ， 用 于 设置 访问 控制 权限 ， 策 略 属 性 
如 表 10-2 所 示 。 


表 10-2 ABAC 模 式 的 策略 属性 








string 如 果 指 定 ， 需 要 和 请 求 认证 
group string 如 果 指 定 ， 需 要 和 请 求 认证 用 户 组 匹配 
readonly boolean 如 果 为 tue， 说 明 只 允许 GET 请 求 
resource string 如 果 指 定 ， 需 要 和 请 求 资源 匹配 


namespace string 如 果 指 定 ， 需 要 和 请 求 资源 所 在 Namespace 



























































REIF I: 


# admin 拥 有 所 有 权限 


{"user":"admin"} 








# _ scheduler 拥 有 读 pods 的 权限 


{"user":"scheduler", "readonly": true,"resource": "pods"} 





# Scheduler 拥 有 读 写 events 的 权限 





{"user": "scheduler", "resource": "events "} 


# kubelet 拥 有 读 pods 的 权限 


{"user":"kubelet", "readonly": true,"resource": "pods"} 





# kubelet 拥 有 读 services 的 权限 





{"user":"kubelet", "readonly": true,"resource": "services"} 


# kubelet 拥 有 读 endpoints 的 权限 





{"user":"kubelet", "readonly": true,"resource": "endpoints"} 


# kubelet 拥 有 读 写 events 的 权限 


{"user":"kubelet", "resource": "events"} 





# alice 拥 有 namespace projectCaribou FARNIR 








{"user":"alice", "namespace": "projectCaribou"} 


# alice 拥 有 namespace projectcaribou 下 的 读 权 限 





{"user":"bob","readonly": true, "namespace": "projectCaribou"} 


# cindy 拥 有 namespace projectcaribou 下 的 pods 的 读 权限 





{"user":"cindy", "resource": "pods", "readonly": true, "namespace": 


10.2.3 准 入 控制 Admission Controller 


请 求 在 认证 和 授权 之 后 ，Kubernetes 提 供 了 Admission Controller 进 
一 步 对 请 求 进行 准 入 控制 。Admission ”Controller 作 为 Kubernetes API 
Server 的 一 部 分 ， 并 以 插件 的 形式 存在 ， 不 过 需要 编译 进 Kubernetes API 
Server 可 执行 程序 才能 使 用 。 





Kubernetes API Server 将 按 顺 序 检查 请 求 ， 如 果 其 中 任何 一 项 没 通 
过 ， 那 么 就 会 拒绝 请 求 。 





Admission Controller 支 持 的 插件 如 表 10-3 所 示 。 


#10-3 Admission Control ler 4&4 


名 称 说 明 

AlwaysAdmit 比 插件 允许 所 有 的 请 求 
AlwaysDeny 此 插件 拒绝 所 有 的 请 求 
ServiceAccount 比 插件 用 于 支持 Service Account 


SecurityContextDeny 比 插件 检查 创建 Pod 的 Security Context 是 否 可 用 ， 不 可 用 的 话 拒绝 





















































ResourceQuota 比 插件 用 于 支持 Resource Quota， 拒 绝对 于 任何 超过 Resource Quota 的 请 求 
LimitRanger 用 于 支持 Limit Ranger， 拒 绝 不 符合 LimitRanger 约 束 的 请 求 
NamespaceLifecycle | 除 一 个 Namespace 会 删除 该 Namespace 下 所 有 的 资源 (pods、services 等 )。 
在 Namespace 被 删除 的 过 程 中 ， 此 插件 将 会 拒绝 任何 试图 在 该 Namespace 下 
创建 新 资源 的 请 求 。 除 此 之 外 ， 拒 绝 试图 在 不 存在 的 Namespace 下 创建 资源 
的 请 求 




































































在 Kubernetes API Server 启 动 的 时 候 ， 可 以 配置 需要 哪些 Admission 
Controller， 以 及 它们 的 顺序 ， 建 议 设置 为 : 


--admission_control=NamespaceLifecycle, LimitRanger, SecurityContex 


10.3 Service Account 


Service Account 概 念 的 引入 是 基于 这 样 的 使 用 场景 : 运行 在 Pod 里 的 
进程 需要 调用 Kubernetes API 以 及 非 Kubernetes API 的 其 他 服务 。 我 们 使 
用 Service Account 来 为 Pod 提 供认 证 。 


Service Account 和 User Account 可 能 会 带 来 一 定 程 度 上 的 混淆 ， 它 们 
的 区 别 如 下 : 


。User Account 通 常 是 为 人 类 设计 的 ， 而 Service Account 则 是 为 运行 
在 Pod 中 的 应 用 设计 的 。 


。 User Account 是 全 局 的 ， 即 可 以 跨 Namespace 使 用 ; 而 Service 
Account 是 限定 Namespace 的 ， 即 仅 在 所 属 的 Namespace 下 使 用 。 


。 创 建 一 个 新 的 User Account 通 名 需要 较 高 的 特权 并 且 需 要 经 过 比较 


复杂 的 业务 逻辑 ， 而 Service Account 则 不 然 。 


提示 


HJ Service Account 功 能 ， 要 添加 Service Account Admission 
Controller， 即 设置 Kubernetes API Server 的 启动 参数 : 


--admission_control=...ServiceAccount... 





Kubernetes API Server 的 相关 局 动 参数 如 表 10-4 所 示 。 
#10-4 Kubernetes API Server 的 启动 参数 


--service- 配置 一 个 包含 PEM-encoded x509 RSA 的 私 钥 或 者 


人 公 钥 ， 用 于 验证 Service Account Token 





Kubernetes Controller Manager 的 相关 启动 参数 如 表 10-5 所 示 。 


表 10-5 Kubernetes Controller Manager 的 启动 参数 





--service-account- 配置 一 个 包含 PEM-encoded x509 RSA 的 私 
private-key-file="" 4H, FS Service Account Token 


__root-ca-file="™" 配置 访问 Kubernetes API Server 的 CA 证 书 ， 将 
赋值 给 Service Account Secret 


10.3.1 使 用 默认 Service Account 





Kubernetes Controller ”Manager 会 为 每 个 Namespace 默 认 创建 一 个 
Service Account， 我 们 称 为 默认 Service Account: 


$ kubectl get serviceaccount 
NAME SECRETS AGE 
default 1 1d 


默认 Service Account 包 含 一 个 Secret: 


$ kubectl describe serviceaccount default 


Name: default 
Namespace: default 
Labels: <none> 


Mountable secrets: default-token-7t9ja 


Tokens: default-token-7t9ja 


Image pull secrets: <none> 


查询 该 Secret: 


$ kubectl describe secret default-token-7t9ja 

Name: default-token-7t9ja 

Namespace: default 

Labels: <none> 

Annotations: kubernetes.io/service-account .name=default, kubernete 


account.uid=... 


Type: kubernetes.io/service-account-token 


Data 


token: 


ca.crt: 1838 bytes 








查询 显示 这 是 一 个 kubernetes.io/service-account-token 类 型 的 Secret， 
称 为 Service Account ”Secret， 包 含 两 个 数据 token 和 ca.crt， 这 也 是 由 
Kubernetes Controller Manager 生 成 的 。 其 中 token 是 由 --service-account- 
private-key-file 指 定 的 密 钥 签发 生成 的 ， 而 ca.crt 是 由 --root-ca-file 指 定 的 
CA 证 书 。 


这 样 一 来 ， 新 建 的 Pod 如 果 没 有 指定 Service Account, WEE H SRA 
Service Account， 挂 载 Service Account Secret) #48 H ae P 
(/var/run/secrets/kubernetes.io/serviceaccount) ，Pod 中 的 应 用 通过 token 
和 ca.crt 访 问 Kubernetes API Server。 同 时 Kuberetes 提 供 非常 方便 的 方式 
让 Pod 获 取 Kubernetes API Server 的 地 址 。Kubernetes 在 初始 化 的 时 候 会 
创建 一 个 Kubernetes Service， 叫 作 kubernetes， 它 代表 的 就 是 Kubernetes 

API Server: 








Kubernetes 在 初始 化 的 时 候 会 创建 一 个 Kubernetes Service， 叫 作 
kubernetes， 它 代表 的 就 是 Kubernetes API Server: 





$ kubectl describe service kubernetes 
Name: kubernetes 
Namespace: default 


Labels: component=apiserver, provider=kubernetes 


Selector: <none> 

Type: ClusterIP 

IP: 10.254.0.1 

Port: https 443/TCP 

Endpoints: 192.168.3.146:6443 
Session Affinity: None 


No events. 


Kubernetes ”Service 的 虚拟 IP 是 10.254.0.1， 这 是 Kubernetes API 
Server 配 置 的 Service 网 段 的 第 一 个 IP (--service-cluster-ip- 
range=10.254.0.0/16) ， 然 后 将 会 转发 HITPS 的 443 端 口 到 
192.168.3.146:6443， 即 Kubernetes API Server 的 地 址 和 HTTPS 安 全 端 
口 。 并 且 Kubernetes ” Service 是 最 早 创建 的 ， 新 建 的 Pod 中 可 以 通过 环境 
变量 获取 来 访问 Kubernetes API Server 〈 也 可 以 通过 DNS 方式 ) : 


KUBERNETES_SERVICE_HOST=10.254.0.1 
KUBERNETES_PORT_443_TCP=tcp://10.254.0.1:443 





KUBERNETES_PORT_443_TCP_PORT=443 





KUBERNETES_PORT_443_TCP_ADDR=10.254.0.1 





KUBERNETES_SERVICE_PORT=443 
KUBERNETES_PORT=tcp://10.254.0.1:443 
KUBERNETES_PORT_443_TCP_PROTO=tcp 





Pod 中 的 进程 就 可 以 访问 Kubemetes API Server， 我 们 现在 简单 实现 
一 个 脚本 curl-k8s- api.sh 来 调用 Kubernetes API: 


#!/bin/sh 


# curl-k8s-api.sh 


Endpoint=$1 
ServiceAccountToken=$(cat /var/run/secrets/kubernetes.io/servicea 
ServiceAccountRootCA=/var/run/secrets/kubernetes.io/serviceaccoun 


KubernetesServerURL="https://$KUBERNETES_SERVICE_HOST : $KUBERNETES 


curl -XGET -H "Authorization: Bearer $ServiceAccountToken" \ 
--cacert $ServiceAccountRootCA \ 


${KubernetesServerURL}${Endpoint} 


脚本 curl-k8s-api.sh 读 取 Service Account 的 token 和 ca.crt， 通 过 环境 变 
量 生 成 URL， 然 后 通过 curl 命 令 调 用 Kubernetes API Server。 我 们 需要 将 
脚本 curl-k8s-api.sh 放 入 Pod 的 容器 中 ， 然 后 访问 /api 获 取 版 本 信息 : 


$ kubectl exec pod -- curl-k8s-api.sh /api 


{ 
"versions": [ 
‘geet 
] 
} 
HAR, Service Account 会 自动 创建 一 个 认证 用 户 ， 用 户 的 命名 格式 
是 : 


system:serviceaccount:[namespace]:[serviceaccountname] 


比如 对 于 在 Namespace my-ns 中 ， 默 认 Service Account 对 应 的 用 户 名 


H 
FE: 
system: serviceaccount :my-ns:default 


如 果 Kubernetes API Server 设 置 了 ABAC 的 授权 模式 ， 需 要 为 Service 
Account 设 置 授 权 策 略 ， 和 否则 会 导致 Pod 无 法 通过 Service Account 访问 
Kubernetes API Server， 比 如 设置 为 只 读 权 限 : 


{"user":"system:serviceaccount: my-ns:default", "readonly": true} 


10.3.2 ”创建 目 定 义 Service Account 


用 户 可 以 创建 自 定义 的 Service Account, Service _ Account 的 定义 文 


件 serviceaccount.yaml: 


apiVersion: v1 
kind: ServiceAccount 
metadata: 


name: my -serviceaccount 


通过 定义 文件 创建 Service Account: 


$ kubectl create -f serviceaccount.yaml 


serviceaccount "my-serviceaccount" created 


A if] Service Account 的 详细 信息 : 


$ kubectl describe serviceaccount my-serviceaccount 


Name: my -serviceaccount 


Namespace: default 


Labels: <none> 


Image pull secrets: <none> 


Mountable secrets: my-serviceaccount-token-ivsm1 


Tokens: my -Sserviceaccount -token-ivsm1 


可 以 看 到 ， 该 Service Account 包含 一 个 Service Account Secret, 
Kubernetes Controller Manager 会 保证 每 个 Service Account 都 至 少 包 含 一 
个 Service Account Secret。 如 采 不 希望 使 用 自动 创建 的 Service Account 
Secret， 可 以 手工 创建 ，Service Account Secret 的 定义 文件 


serviceaccountSecret.yaml: 


apiVersion: v1 
kind: Secret 
metadata: 
name: my-serviceaccount-secret 
annotations: 
kubernetes.i0/service-account.name: my-serviceaccount 


type: kubernetes.io/service-account -token 


通过 定义 文件 创建 Service Account Secret: 


$ kubectl create -f serviceaccountSecret.yaml 


secret "my-serviceaccount-secret" created 


添加 创建 好 的 Service Account Secret 到 Service Account: 


$ kubectl patch serviceaccount my-serviceaccount \ 
-p '{"secrets": [{"name": "my-serviceaccount-secret"}]}' 


"my-serviceaccount" patched 


然后 删除 自动 创建 的 Service Account Secret: 


$ kubectl delete secret my-serviceaccount -token-ivsm1 


secret "my-serviceaccount-token-ivsmi" deleted 


IX FELD E Hh S Service Account Secret: 


$ kubectl describe serviceaccount my-serviceaccount 
Name: my-serviceaccount 
Namespace: default 


Labels: <none> 


Image pull secrets: <none> 


Mountable secrets: my-serviceaccount-secret 


Tokens: my-serviceaccount-secret 


在 Pod 的 定义 中 可 以 通过 .spec.serviceAccountName 指 定 Service 
Account， 如 下 所 示 : 


apiVersion: v1 


kind: Pod 


metadata: 

name: busybox 

namespace: default 

spec: 

containers: 

- name: busybox 
image: busybox 
command: 

- sleep 
- "3600" 
restartPolicy: Always 


serviceAccountName: my-serviceaccount 


10.3.3 Service Accounti 示 加 Image Pull 
Secret 


在 Service Account 中 添加 Image Pull Secret 时 ， 当 Pod 使 用 该 Service 
Account 的 时 候 就 自动 关联 上 其 中 的 Image Pull Secret; 而 当 为 默认 
Service _ Account 添加 Image Pull Secret 时 ， 那 么 Pod 会 自动 关联 上 Image 
Pull Secret， 不 必 显 示 配 置 。 


首先 创建 一 个 Image Pull Secret， 可 参考 4.3.1 市 : 


$ kubectl get secret myregistrykey 
NAME TYPE DATA AGE 


myregistrykey kubernetes.io/dockercfg 1 1h 


添加 Image Pull Secret 到 默认 Service Account: 


$ kubectl patch serviceaccounts default \ 
-p '{"imagePullSecrets": [{"name": "myregistrykey"}]}' 
"default" patched 


修改 默认 Service Account 成 功 后 ， 可 以 查询 到 Image Pull Secret 添 加 
成 功 : 


$ kubectl describe serviceaccounts default 
Name: default 

Namespace: default 

Labels: <none> 


Image pull secrets: myregistrykey 
Mountable secrets: default-token-mymp9 


Tokens: default -token-mymp9 


这 样 一 来 ， 新 创建 的 Pod 都 会 自动 关联 上 Image Pull Secret: 


spec: 
imagePullSecrets: 


- name: myregistrykey 


10.4 FRLET 


10.4.1 Linux Capability 


Docker 对 于 容器 中 的 root 用 户 是 进行 限制 的 ， 这 是 基于 Linux 内 核 的 
Capability 机 制 实现 的 。Linux Capability 将 内 核 系 统 资源 访问 划分 为 许多 
的 权限 属性 ， 从 而 可 以 对 权限 进行 精细 化 管理 。 


对 于 Docker 容 右 中 的 root 用 户 ， 很 多 系统 相关 的 操作 权限 都 是 被 剥 
夺 的 ， 只 有 具备 超级 用 户 的 一 些 基 本 权限 。 如 果 需 要 授予 Docker 容 髓 足够 
的 权限 ， 可 以 使 用 特权 模式 ， 即 设置 docker run 的 参数 --privileged=ture。 


在 Pod 的 定义 中 可 以 通 
过 .spec.containers[].securityContext.privileged=true 设 置 容 右 的 特权 模式 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: nfs-server 
labels: 
role: nfs-server 
spec: 
containers: 
- name: nfs-server 
image: jsafrane/nfs-data 
ports: 
- name: nfs 
containerPort: 2049 


securityContext: 


privileged: true 


Vv Sve 
VE RR 





Pod 中 的 容器 要 设置 特权 模式 ， 需 要 设置 Kubernetes API Server 和 


Kubelet 的 启动 参数 --allow-privileged=ture 来 允许 开启 容器 的 特权 模 
INe 





当 Docker 容 器 设置 了 特权 模式 之 后 ， 那 么 Docker 容 器 的 root 权 限 将 
得 到 大 幅度 提升 。 由 于 Docker 容 器 与 答 主 机 处 于 共享 同一 个 内 核 操 作 系 
统 的 状态 ， 因 此 Docker 容 器 将 完全 拥有 内 核 的 管理 权限 ， 这 束 存 在 安全 





而 且 对 应 用 程序 来 说 ， 往 往 只 需要 特定 的 权限 ， 比 如 一 个 程序 需要 
使 用 ping 命 令 ， 这 是 一 个 SUID 命 令 ， 会 以 root 权 限 运 行 ， 而 实际 上 这 个 
程序 只 是 需要 RAW 套 接 字 建立 必要 ICMP 数 据 包 ， 除 此 之 外 的 其 他 root 
权限 对 这 个 程序 都 是 没有 必要 的 。 








Docker 支 持 添加 和 删除 容器 的 Linux Capability， 即 docker run 命 令 
的 --cap-add 和 --cap-drop 参 数 。 在 Pod 的 定义 中 可 以 通 
过 .spec.containers[].securityContext.capabilities.add 
和 .spec.containers[].securityContext.capabilities.drop 这 加 和 删除 容器 的 
Linux Capability: 


apiVersion: v1 


kind: Pod 


metadata: 
name: nfs-server2 
labels: 

role: nfs-server 

spec: 
containers: 

- name: nfs-server 
image: nginx 
ports: 

- name: nfs 
containerPort: 2049 
securityContext: 
Capabilities: 
add: 
- IPC_LOCK 
- NET_ADMIN 
drop: 
- SETGID 


10.4.2 SELinux 


SELinux (Security Enhanced Linux) 是 Linux 内 核 的 安全 模块 ， 提 供 
了 一 种 灵活 的 强制 访问 控制 系统 。SELinux 拥 有 一 个 灵活 而 强制 性 的 访 
问 控制 结构 ， 上 旨 在 提高 Linux 系 统 的 安全 性 ， 提 供 强 健 的 安全 保证 。 





Docker 支 持 使 用 SELinux 进 行 安全 加 固 ， 通 过 SELinux 可 以 根据 类 别 





和 MCS/MLS 等 级 来 区 分 进程 ， 保 护 宿 主机 不 受 容 器 影响 。 
docker run 中 通过 --security-opt 可 MÉ HA 4s KIMCS/MLS tp 


--security-opt="label:user:USER" 
--security-opt="label:role:ROLE" 
--security-opt="label: type: TYPE" 


--security-opt="label:level:LEVEL" 


相应 的 ， 在 Pod 的 定义 中 可 按 如 下 方式 修改 容器 的 MCS/MLS 标 签 : 


securityContext: 

seLinuxOptions: 
user: USER 
role: ROLE 
type: TYPE 


level: LEVEL 


10.5 多 租户 


多 租户 是 云 计 算 中 的 一 个 重要 能 力 ， 是 云 计算 集中 式 的 数据 中 心 ， 
以 服务 的 形式 提供 给 用 户 。 多 租户 是 共享 和 隔离 互相 作用 下 的 产物 ， 用 
户 需要 处 在 不 同 的 租户 下 ， 同 租户 内 部 是 共享 的 ， 但 是 不 同 租户 之 间 是 
隔离 的 。 

















Kubernetes 中 的 Namespace 就 是 租户 的 概念 ，Kubernetes 整 个 平台 的 
内 容 通 过 Namespace 划 分 为 多 个 逻辑 平面 ， 不 同 个 人 或 者 团队 在 不 同 
Namespace 中 共享 Kubernetes，Namespace 之 间 互 相 不 感知 。 


Kubernetes 以 Namespace 作 为 管理 单位 ， 可 以 控制 安全 访问 策略 ， 设 
置 资源 配额 等 ， 为 此 需要 使 用 Kubernetes 规 划 好 Namespace， 比 如 可 以 根 
据 功 能 、 区 域 、 部 门 或 者 业务 等 。 


我 们 可 以 像 其 他 API 对 象 一 样 创 建 Namespace，Namespace 定 义 文 件 


development- namespace.yaml: 


apiVersion: v1 
kind: Namespace 
metadata: 
name: development 
labels: 


name: development 


通过 定义 文件 创建 Namespace: 


$ kubectl create -f development -namespace.yaml 


namespace "development" created 


创建 成 功 后 可 以 查询 Namespace: 


$ kubectl describe namespace development 
Name: development 
Labels: name=development 


Status: Active 


No resource quota. 


No resource limits. 


第 11 章 
Kubernetes 资 源 管 理 


资源 管理 是 Kubernetes 的 一 个 关键 能 力 ，Kubernetes 需 要 为 应 用 分 配 
足够 的 资源 ， 又 要 防止 应 用 无 限制 使 用 资源 ， 随 痢 应 用 规模 数量 级 的 增 
加 ， 这 些 问题 就 显得 至 关 重 要 。 本 章 将 前 述 Kubernetes 资 源 管 理 的 模型 
和 具体 实现 方法 ， 包 括 资源 分 配 策略 和 配额 限制 等 。 





11.1 Kubernetes 资 源 模型 


虚拟 化 技术 是 云 计算 平台 的 基础 ， 其 目标 是 对 计算 资源 进行 整合 或 
划分 ， 这 是 云 计 算 管 理 平台 中 的 关键 技术 。 虚 拟 化 技术 为 云 计 算 管理 平 
台 的 资源 管理 提供 了 资源 调配 上 的 灵活 性 ， 从 而 使 得 云 计算 管理 平台 可 
以 通过 虚拟 化 层 整合 或 划分 计算 资源 。 





相 比 于 虚拟 机 ， 新 出 现 的 容器 技术 使 用 了 一 系列 的 系统 级 别 的 机 
制 ， 诸 如 利用 Linux Namespace 进 行 空间 隔离 ， 通 过 文件 系统 的 挂 载 点 
决定 容器 可 以 访问 哪些 文件 ， 通 过 Cgroup 确 定 每 个 容器 可 以 利用 多 少 资 
源 。 此 外 ， 容 器 之 间 共 享 同 一 个 系统 内 核 ， 这 样 当 同一 个 内 核 被 多 个 容 
器 使 用 时 ， 内 存 的 使 用 效率 会 得 到 提升 。 


容 锅 和 虚拟 机 两 大 虚拟 化 技术 ， 虽 然 实现 方式 完全 不 同 ， 但 是 它们 
的 资源 需求 和 模型 其 实 是 类 似 的 。 容 器 像 虚 拟 机 一 样 青 要 内 存 、CPU、 
硬盘 空间 和 网 络 带宽 ， 和 宿主 机 系统 可 以 将 虚拟 机 和 容器 都 视 作 一 个 整 
体 ， 为 这 个 整体 分 配 其 所 需 的 资源 ， 并 进行 管理 。 当 然 ， 虚 拟 机 提供 了 


专用 操作 系统 的 安全 性 和 更 牢固 的 轴 辑 边界 ， 而 容器 在 资源 边界 上 比较 
松散 ， 这 而 来 了 灵活 性 以 及 不 确定 性 。 


Kubernetes 是 一 个 容器 集群 管理 平台 ，Kubernetes 需 要 统计 整体 平台 
的 资源 使 用 情况 ， 合 理 地 将 资源 分 配给 容器 使 用 ， 并 且 要 保证 容器 生命 
周期 内 有 足够 的 资源 来 保证 其 运行 。 更 进一步 ， 如 果 资 源 发 放 是 独占 
的 ， 即 资源 已 发 放 给 了 一 个 容器 ， 同 样 的 资源 不 会 发 放 给 另外 一 个 容 
器 ， 对 于 空闲 的 容 堪 来 说 占用 着 没有 使 用 的 资源 〈 比 如 CPU) eS FAIR 
费 的 ，Kubernetes 需 要 考虑 如 何在 优先 度 和 公平 性 的 前 提 下 提 融 资源 的 
利用 率 。 


11.2 资 源 请 求 和 限制 


计算 资源 是 Pod 或 者 容器 运行 所 需 的 ， 包 括 : 








«CPU 
单位 是 核 (core) 。 


cpu: 1 #1 核 
cpu: 0.25 #0.25%% 
cpu: 250m #0.25t% 


。 内 存 (Memory) 
单位 是 字 节 (byte) 。 


memory: 1024 #1024 Byte 


memory: 512Ki #512 KByte 
memory: 256Mi #256 MByte 


memory: 1.5Gi #1.5 GByte 


创建 Pod 的 时 候 ， 可 以 指定 每 个 容器 的 资源 请 求 (Request) 和 资源 
限制 (Limit〉， 资 源 请 求 是 容器 所 需 的 最 小 资源 需求 ， 资 源 限制 则 是 
容 右 不 能 超过 的 资源 上 限 ， 它 们 的 大 小 关系 必须 是 : 





0 <= request <= limit <= Infinity 


在 容器 的 定义 中 ， 资 源 请 求 通过 resources.requests 设 置 ， 资 源 限制 
通过 resources.limits 设 置 ， 目 前 可 以 指定 的 资源 类 型 只 有 CPU 和 内 存 。 
资源 请 求 和 限制 是 可 选 配 置 ， 上 默认 值 根据 是 否 设 置 Limit Range 而 定 。 如 
果 资 源 请 求 没有 指定 也 没有 默认 值 ， 那 么 资源 请 求 就 等 于 资源 限制 。 











以 下 定义 的 Pod 包 含 两 个 容器 : 第 一 个 容器 的 资源 请 求 是 0.5 核 CPU 
和 256 MByte 内 存 ， 资 源 限制 是 1 核 CPU 和 512 MByte 内 存 ; 第 二 个 容器 
的 资源 请 求 是 0.25 核 CPU 和 128MByte 内 存 ， 资 源 限制 是 1 核 CPU 和 512 
MByte 内 存 : 


apiVersion: v1 
kind: Pod 
metadata: 

name: frontend 
spec: 

containers: 

- name: db 


image: mysql 


resources: 
requests: 
memory: "256Mi" 
cpu: "500m" 
limits: 
memory: "512Mi" 
cpu: "1000m" 
- name: wp 
image: wordpress 
resources: 
requests: 
memory: "128Mi" 
cpu: "250m" 
limits: 
memory: "512Mi" 


cpu: "1000m" 





Pod 的 资源 请 求 /限制 是 Pod 中 所 有 容器 资源 请 求 /限制 的 和 ， 比 如 该 
Pod 的 资源 请 求 是 0.75 核 CPU 和 384MByte 内 存 ， 资 源 限制 是 2 核 CPU 和 
1024MByte 内 存 。 


Kubernetes 在 调度 Pod 的 时 候 ，Pod 的 资源 请 求 是 调度 的 一 个 关键 指 
标 。Kubernetes 会 获取 Kubernetes Node 的 最 大 资源 容量 (通过 cAdvisor 接 
口 ) ， 并 计算 出 已 使 用 的 资源 情况 ， 比 如 Node 能 够 容纳 2 核 CPI 和 
2GByte 内 存 ，Node 上 已 经 运作 了 4 个 Pod， 共 请 求 1.5 核 CPU 和 1GByte 内 
存 ， 剩 余 0.5 核 CPU 和 1GByte 内 存 。Kubernetes Scheduler 调 上 度 Pod 的 时 候 
会 检查 Node 上 是 否 还 有 足够 资源 来 满足 Pod 的 资源 请 求 ， 不 满足 则 将 该 


Node 排 除 。 


资源 请 求 能 够 保证 Pod 有 足够 的 资源 来 运行 ， 而 资源 限制 则 是 防止 
茶 个 Pod 无 限制 地 使 用 资源 ， 导 人 致 其 他 Pod 册 沉 。 特 别 是 在 公有 云 场 景 ， 
往往 会 有 亚 意 软件 通过 抢占 内 存 来 攻击 平台 。 











Docker 容 器 是 使 用 Linux Cgroup 来 实现 资源 限制 的 ，docker runi fE 
供 了 参数 对 CPU 和 内 存 进行 限制 。 


e --memory 


docker run 通过--memory 给 一 个 容器 可 用 的 内 存 配额 ，Cgroup 
会 限制 容器 的 内 存 使 用 ， 一 旦 超过 配额 ， 容 器 将 会 被 终止 。 


Kubernetes 中 Docker 容 器 的 --memory 值 就 是 resources.limits.memory 
的 值 ， 比 如 resources.limits.memory=512Mi， 那 么 --memory 的 值 就 是 
512*1024*1024*1024。 


e --cpu-shares 


docker run 通 过 --cpu-shares 设 置 一 个 容器 的 可 用 的 CPU 配额 。 需 

要 特别 注意 的 是 ， 这 是 一 个 相对 权重 ， 与 实际 的 处 理 速度 无 关 。 
个 新 的 容器 默认 将 有 1024 CPU 配额 ， 当 我 们 单独 讲 它 的 时 候 ， 这 个 
值 并 不 意味 着 什么 。 但 是 如 果 启 动 两 个 容器 并 且 两 个 都 将 使 用 
100% 的 CPU，CPU 时 间 将 在 这 两 个 容器 之 间 平 均 分 割 ， 因 为 它们 
两 个 都 有 同样 的 CPU 配额 。 如 果 我 们 设置 容器 的 CPU 配额 是 512， 
相对 于 另外 一 个 1024 CPU 配额 容器 ， 它 将 使 用 1/3 的 CPU 时 间 。 但 
这 不 意味 着 它 仅仅 能 使 用 13 的 CPU 时 间 。 如 果 另 外 一 个 容器 

(1024 CPU 配额 的 ) 是 空间 的 ， 其 他 容器 将 被 允许 使 用 100% 








CPU。 对 于 CPU 来 说 ， 难 以 清楚 地 说 明 多 少 CPU 被 分 配给 了 哪个 容 
器 ， 这 取决 于 实际 的 运行 情况 。 





Kubernetes 中 Docker 容 器 的 --cpu-shares 值 通过 resources.requests.cpu 
或 者 resources. requests.cpu 乘 以 1024 而 得 。 如 果 指 定 
resources.requests.cpu, 4) 4--cpu-shares “4: }-resources.requests.cpude VA 
1024， 如 果 没 有 指定 resources.requests.cpu， 但 是 指定 了 resources. 
limits.cpu， 那 么 --cpu-shares 束 等 于 resources.limits.cpu 滋 以 1024， 如 果 
resources.limits.cpu 和 resources.limits.cpu 都 没有 指定 ， 那 么 


resources.resources.cpu 就 取 最 小 值 〈 当 前 版 本 最 小 值 为 2) ， 有 具体 如 下 : 


if resources.requests.cpu is definded 
cpuShares=resources.requests.cpu * 1024 
else if resources.requests.cpu is undefined 
if resources.limits.cpu is defined 
cpuShares=resources.limits.cpu * 1024 
else if resources.limits.cpu is defined 


cpuShares = minShares 


tt iiresources.requests.cpu=250m, RA --cpu-share HA wt z 
250m*1024=256. 


11.3 Limit Range 








Limit Range 设 计 的 初衷 是 为 了 满足 以 下 场景 : 


© 能 够 约束 租户 的 资源 需求 。 


“能够 约束 容器 的 资源 请 求 范围 。 
“ 能 够 约束 Pod 的 资源 请 求 范 围 。 
© 能 够 指定 容器 的 默认 资源 限制 。 
© 能 够 指定 Pod 的 默认 资源 限制 。 


© 能 够 约束 资源 请 求 和 限制 之 间 的 比例 。 


提示 


Kubernetes 要 开启 Limit “Range 功 能， 首先 要 添加 Limit Range 


Admission Controller， 即 设置 Kubernetes API Server 的 局 动 参数 : 


--admission_control=...LimitRange... 





Limit Range 包 含 两 种 类 型 的 设置 : Container 和 Pod， 包 含 约束 和 默 
认 值 的 配置 ， 如 表 11-1 和 表 11-2 所 示 。 


表 11-1 Limit Range Container 配置 





HK 
A Container 


VR 
Dan 


源 | memory 


cpu 





min: min <= Request (required) <= Limit (optional) 

约 max: Limit (required) <= max 

W maxLimitRequestRatio: maxLimitRequestRatio <= ( Limit 
(required,non-zero) / Request (required,non-zero) 





PR default: Limit 的 默认 值 
fei defaultRequest: Request 的 默认 值 





表 11-2 Limit Range Pod 配 置 





IR 


资 
源 memory 













min: min <= Request (required) <= Limit (optional) 

max: Limit (required) <= max 

maxLimitRequestRatio: (Limit (required,non-zero) / Request 
(required,non-zero) maxLimitRequestRatio 


Pod RVA ERME. A Aas ER VUE IT 





创建 Limit Range 的 时 候 需 要 注意 以 下 几 点 。 


“配置 效 值 的 时 候 需 要 满足 以 下 条 件 


Min (if specified) <= DefaultRequest (if specified) <= Default (i 


e 默认 值 行为 


当 Default 未 设置 : 


if LimitRangeItem.Default[resourceName] is undefined 
if LimitRangeItem.Max[resourceName] is defined 


LimitRangeItem.Default[resourceName] = LimitRangeItem.Max[res 


“4DefaultRequest i H : 


if LimitRangeItem.DefaultRequest[resourceName] is undefined 
if LimitRangeItem.Default[resourceName] is defined 
LimitRangeItem.DefaultRequest[resourceName] = LimitRangeItem. 
else if LimitRangeItem.Min[resourceName] is defined 


LimitRangeItem.DefaultRequest[resourceName] = LimitRangelItem. 


当 在 Namespace 下 创建 Limit RangeJa, LAY LAV Pode 448 1) ot 
源 请 求 和 限制 默认 值 ， 更 重要 的 功能 是 对 Pod 和 容器 的 资源 规格 配置 进 
行 约束 。 现 在 我 们 在 Namespace development 下 创建 一 个 Limit Range, 
Limit Range 的 定义 文件 limits.yaml: 





apiVersion: v1 
kind: LimitRange 
metadata: 


name: limits 


namespace: development 


spec: 
limits: 
- type: Pod 
max: 
cpu: 4 
memory: 2G1 
min: 


cpu: 250m 
memory: 8Mi 
maxLimitRequestRatio: 
cpu: 4 
memory: 4 
- type: Container 
default: 
cpu: 500m 
memory: 512Mi 
defaultRequest: 
cpu: 250m 
memory: 256Mi 
max: 
cpu: 2 
memory: 1Gi 
min: 
cpu: 250m 
memory: 8Mi 


maxLimitRequestRatio: 


cpu: 2 


memory: 2 


通过 定义 文件 创建 Limit Range: 


$ kubectl create -f limits.yaml 


limitrange "limits" created 


创建 成 功 ， 查 询 Limit Range: 


$ kubectl describe limitranges limits --namespace=development 
Name: limits 
Namespace: development 


Type Resource Min Max Request Limit Limit/Request 


Pod cpu 250m 4 - - 4 

Pod memory 8Mi 2G1 - - 4 

Container cpu 250m 2 250m 500m 2 
Container memory 8Mi 1Gi 256Mi 512Mi 2 


对 于 以 上 内 容 有 以 下 几 点 说 明 。 

“默认 值 

1. 一 个 容器 的 默认 资源 请 求 是 256Mbyte 内 存 和 250m 核 CPU。 
2. 一 个 容器 的 默认 资源 限制 是 512Mbyte 内 存 和 500m 核 CPU。 


。 约束 


1. 一 个 Pod 的 资源 请 求 和 限制 必须 满足 : 


250m <= requests.cpu <= limits.cpu <= 4 
8Mi <= requests.memory <= limits.memory <= 2Gi 
limits.memory/requests.memory <= 4 


limits.cpu/requests.cpu <= 4 
2. 一 个 容器 的 资源 请 求 和 限制 必须 满足 : 


250m <= requests.cpu <= limits.cpu <= 2 
8Mi <= requests.memory <= limits.memory <= 1Gi 
limits.memory/requests.memory <= 2 


limits.cpu/requests.cpu <= 2 


至 此 ， 在 Namespace development 中 创建 的 Pod 都 需要 满足 以 上 约 
束 ， 比 如 创建 一 个 Pod，Pod 的 定义 文件 test-pod.yaml: 


apiVersion: v1 
kind: Pod 
metadata: 
name: test 
namespace: development 
spec: 
containers: 
- name: containert 
image: nginx 
resources: 


requests: 


memory: 512Mi 

cpu: "999m" 
limits: 

memory: "512Mi" 

cpu: "2" 

- name: container2 
image: nginx 
resources: 

requests: 
memory: 512Mi 
cpu: "250m" 
limits: 
memory: "1Gi" 
cpu: "500m" 

- name: container3 
image: nginx 
resources: 

requests: 
memory: 8ki 
cpu: "250m" 
limits: 
memory: "1Gi" 


cpu: "500m" 


创建 Pod 会 失败 : 


$ kubectl create -f test-pod.yaml 


Error from server: error when creating "test-pod.yaml": Pod "test 
Maximum memory usage per Pod is 2Gi, but limit is 2684354560., 
cpu max limit to request ratio per Container is 2, but provided i 
Minimum memory usage per Container is 8Mi, but request is 8Ki., 


memory max limit to request ratio per Container is 2, but provide 


其 中 有 4 个 错误 : 


1. Pod 的 最 大 内 存 为 2Gi， 但 是 创建 的 Pod 资 源 限 制 是 
1Gi+1Gi+512Mi=2684354560 。 


2， 容 器 的 CPU 限制 和 请 求 比 例 不 能 超过 2， 容 器 container1 的 CPU 限 
制 和 请 求 比例 为 2/0999m=2.002002。 


3. 容器 的 最 小 内 存 是 8mi， 容 器 container3 的 CPU 请 求 是 8Ki。 


， 容 器 的 内 存 限制 和 请 求 比例 不 能 超过 2， 容 器 container3 的 内 存 限 
求 比 例 为 500m /8ki =131072.000000。 


11.4 Resource Quota 


Kubernetes 是 一 个 多 租户 架构 ， 当 多 用 户 或 者 团队 共享 一 个 
Kubernetes 系 统 的 时 候 ， 系 统管 理 员 需要 防止 租户 的 资源 强占 ， 定 义 好 
资源 分 配 策略 。 比 如 Kubernetes 系 统 共 有 20 核 CPU 和 32GByte 内 存 ， 分 配 
给 A 租 户 5 核 CPU 和 16 GByte， 分 配给 B 租 户 5 核 CPU 和 8GByte， 预 留 10 
核 CPU 和 8GByte 内 存 。 这 样 ， 租 户 中 所 使 用 的 CPU 和 内 存 的 总 和 不 能 超 
过 指定 的 资源 配额 ， 促 使 其 更 合理 地 使 用 资源 。 


Kubernetes 中 提供 API 对 象 Resource Quota〈 资 源 配额 ) 来 实现 资源 
配额 ，Resource ”Quota 不 仅 可 以 作用 于 CPU 和 内 存 ， 另 外 还 可 以 限制 比 
如 创建 Pod 的 数目 。Resource Quota sz FF WRH WN ZS 11-34 ZE11-4 TN 





。 计 算 资源 配额 


表 11-3 计算 资源 配额 





资源 名 称 说 明 
cpu CPU 配额 
memory 内 存 配额 


限制 计算 资源 的 使 用 ，Namespace 中 所 有 Pod 的 资源 请 求 总 和 不 能 超 
过 配额 ， 比 如 Namespace A 的 内 存 配额 为 1GByte， 那 么 Namespace A 中 
所 有 Pod 的 Memory 请 求 总 和 ， 即 resources.requests.memory 的 总 和 不 能 超 


过 1GByte。 





。Kubernetes API 对 象 资源 配额 


#11-4 Kubernetes AP1 对 象 资源 配额 


资源 名 称 说 明 
pods Pod 的 总 数目 
services Service 的 总 数目 


replicationcontrollers Replication Controller 的 总 数目 














resourcequotas Resource Quota 的 总 数目 


Secrets Secret 的 总 数 





























persistentvolumeclaims Persistent Volume Claim 的 总 数目 


限制 Kubernetes _ API 对象 的 创建 数目 ，Namespace 中 API 对 象 的 创建 
数目 不 能 超过 配额 ， 比 如 限制 Namespace A 的 Pod 和 Service 的 创建 数目 。 


提示 


Kubernetes 要 开启 Resource Quota 支持 ， 首 先 要 添加 Resource 
Quota Admission Controller， 即 设置 Kubernetes API Server 的 局 动 参 
数 : 


--admission_control=...ResourceQuota... 





默认 情况 下 ，Namespace 是 没有 Resource ”Quota 的 ， 需 要 另外 创建 


Resource Quota。 一 般 情 况 下 ， 一 个 Namespace 下 配置 一 个 Resource 
Quota 即 可 ， 但 是 可 以 创建 多 个 Resource Quota， 将 按 多 个 Resource 


Quota 最 小 值 作为 配额 值 。 比 如 一 个 Resource Quota 设 置 Pod 的 数目 配额 
为 10， 另 一 个 Resource Quota 设 置 Pod 的 数目 配额 为 5， 那 么 Pod 的 数目 不 
能 超过 5。 


现在 我 们 在 Namespace ”development 下 创建 一 个 Resource Quota, 
Resource Quota 的 定义 文件 quota.yaml: 


apiVersion: v1 
kind: ResourceQuota 
metadata: 

name: quota 


namespace: development 


spec: 
hard: 

cpu: "20" 
memory: 50Gi 
persistentvolumeclaims: "10" 
pods: "10" 
replicationcontrollers: "20" 
resourcequotas: "1" 
secrets: "10" 


services: "5" 


通过 定义 文件 创建 Resource Quota: 


$ kubectl create -f quota.yaml 


resourcequota "quota" created 


创建 成 功 后 可 以 查询 Resource Quota， 其 中 包括 配额 值 和 使 用 值 : 


$ kubectl describe resourcequota quota --namespace=development 


Name: quota 

Namespace: development 
Resource Used Hard 
cpu 0 20 

memory © 1Gi 


persistentvolumeclaims © 10 
pods © 10 


replicationcontrollers © 20 


resourcequotas 1 1 
secrets 1 10 


services 0 5 


— H Namespace Resource Quota， 创 建 Pod 的 时 候 就 必须 指定 资源 
请 求 ， 否 则 Pod 会 创建 失败 〈Kubernetes 返 回 403 FORBIDDEN) 。 同 样 
的 ，Pod 请 求 的 资源 超过 了 资源 配额 也 会 创建 失败 〈Kubernetes 将 返回 
403 FORBIDDEN) 。 


现在 在 Namespace ”development 下 创建 一 个 Pod， 请 求 0.25 核 CPU 和 
128MByte 的 内 存 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: nginx 
namespace: development 
spec: 
containers: 
- name: nginx 
image: nginx 
ports: 
- containerPort: 80 
protocol: TCP 
resources: 
requests: 
memory: "128Mi" 


cpu: "250m" 


limits: 
memory: "512Mi" 


cpu: "500m" 


在 Pod 创 建成 功 后 ， 可 以 查询 到 相应 的 资源 使 用 情况 ， 共 消耗 1 个 
Pod， 以 及 0.25 核 CPU 和 128MByte 的 内 存 : 


$ kubectl describe resourcequota quota --namespace=development 


Name: quota 

Namespace: development 
Resource Used Hard 
cpu 250m 20 

memory 134217728 1Gi 


persistentvolumeclaims 0 10 
pods 1 10 
replicationcontrollers 0 20 
resourcequotas 1 1 

secrets 1 10 


services 0 5 


第 12 章 
管理 和 运 维 Kubernetes 


Kubernetes 问 下 接管 底层 资源 ， 回 上 托管 业务 应 用 ， 要 管理 和 运 维 
这 样 一 套 系 统 可 以 说 是 一 个 巨大 的 挑战 。 幸 运 的 是 ，Kubernetes 已 经 提 
供 了 一 些 很 好 的 支持 来 帮助 管理 Kubernetes。 本 章 将 介绍 Kubernetes 的 高 


可 靠 性 方案 、 平 台 监控 、 平 台 日 志 等 。 








12.1 Daemon Pod 


从 系统 管理 的 需求 来 说 ， 我 们 常常 需要 在 Kubernetes 的 所 有 市 点 上 
运行 一 些 守 护 进程 (Daemon) ， 比 如 日 志 收 集 、 监 控 等 。 传 统 的 做 法 
是 使 用 一 些 Init 工 具 (比如 init、upstartd， 或 者 systemd) 来 进行 管理 ， 
而 Kubernetes 中 文 持 以 Pod 的 形式 运行 这 些 守 护 进程 ， 我 们 称 为 Daemon 
Pod， 实 现 的 方式 包括 Static Pod 和 Daemon Set。 


12.1.1 Static Pod 


Static Pod 是 直接 由 Kubelet 组 件 创建 、 运 行 在 Node 上 的 Pod，Kubelet 
组 件 负责 Static Pod 的 持续 运行 ， 而 无 须 Replication Controller 进 行 关联 管 
理 。 这 样 一 来 ，Static Pod 就 同 Kubelet 进 行 绑 定 ， 从 而 运行 在 Node 上 作 


为 Daemon Pod。 


Static ”Pod 的 创建 是 通过 在 Kubelet 指 定 的 Manifest 目 录 中 放 入 Pod 的 
定义 文件 (JSON 或 者 YAML 格 式 ) 进行 的 ，Manifest 目 录 是 通过 Kubelet 
的 局 动 参数 --config 配 置 的 。 本 书 Kubernetes 运 行 环 境 指定 Kubelet 的 
Manifest 目 录 为 /etc/kubernetes/manifests。 





现在 通过 Static Pod 在 Kubernetes Node 上 运行 Prometheus， 一 个 开源 
的 服务 监控 系统 ， 可 以 实现 对 Docker 容 器 进行 监控 。 这 需要 在 所 有 Node 
上 的 Manifest 目 录 中 创建 Static Pod 的 定义 文件 prometheus-node- 


exporter.yaml: 


apiVersion: v1 
kind: Pod 
metadata: 
name: prometheus-node-exporter 
labels: 
daemon: prom-node-exp 
spec: 
containers: 
- name: c 
image: prom/prometheus 
ports: 
- name: serverport 
containerPort: 9090 


hostPort: 9090 


Kubelet 将 在 Node 上 运行 Static Pod, F Static Pod 的 名 称 是 Pod 名 称 
拼接 上 Node 的 名 称 : [pod_name]-[node_name]: 


$ kubectl get pod --selector daemon=prom-node-exp --output wide 


NAME READY STATUS 
prometheus-node-exporter -kube-node-1 1/1 Running 0 
prometheus-node-exporter -kube-node-2 1/1 Running 0 
prometheus-node-exporter -kube-node-3 1/1 Running 0 


如 果 删 除 该 Static Pod，Kubelet 会 重新 创建 Static Pod， 保 证 其 持续 
运行 ， 而 只 有 在 Manifest 目 录 中 删除 该 Static Pod 的 定义 文件 ，Static Pod 
才 会 被 删除 。 


除了 直接 在 Manifest 目 录 中 放 入 Static ”Pod 定 义 文件 ， 还 可 以 通过 
Kubelet 的 启动 参数 --manifest-url=<URL> 指 定 远程 URL，Kubelet 将 定期 
下 载 Static Pod 的 定义 文件 进行 创建 或 者 更 新 。 


使 用 Static Pod 能 够 运行 Daemon Pod， 但 是 Static Pod 的 管理 是 比较 
低 效 的 。 比 如 发 生变 更 ， 就 可 能 需要 修改 每 个 Node 上 的 Kubelet 配 置 。 
为 此 ，Kubernetes 提 供 了 一 个 更 加 强大 的 机 制 来 管理 运行 Daemon Pod. 


12.1.2 Daemon Set 


Kubernetes#i¢£ [Daemon Set， 用 来 在 Kubernetes Node 上 创建 运行 
Daemon Pod. Daemon Set 的 作用 同 Replication Controller 类 似 ， 它 们 都 是 
管理 控制 Pod 的 ， 只 不 过 Daemon Set 是 保证 所 有 【或 者 部 分 ) Node 上 都 
能 够 运行 Daemon Pod。 


提示 


在 当前 版 本 (Kubernetes v1.1.1) 中 ，Daemon Set 是 Beta 测试 阶 
段 ， 需 要 设置 Kubernetes API Server 启 动 参数 --runtime- 


config=extensions/vlbetal/daemonsets=true 来 开启 Daemon Set 支 持 。 





现在 通过 Daemon Set 在 Kubernetes Node 上 运行 Prometheus，Daemon 


Set 的 定义 文件 prometheus-node-exporter.yaml: 


apiVersion: extensions/vibetal 
kind: DaemonSet 
metadata: 

name: prometheus-node-exporter 
spec: 


template: 


metadata: 
labels: 
daemon: prom-node-exp 
spec: 
containers: 
- name: c 
image: prom/prometheus 
ports: 
- name: serverport 
containerPort: 9090 


hostPort: 9090 


可 以 看 出 ，Daemon _ Set 的 定义 和 Replication 


Controller 类 似 ， 通 


过 .spec.template 设 置 Pod 的 模板 。 因 为 Daemon Pod 需 要 持续 运行 ， 所 以 
Pod 的 模板 中 的 重启 策略 只 能 是 Always。 





在 默认 情况 下 ，Daemon Set 会 在 所 有 Node 上 运行 Daemon Pod, iff 
过 .spec.template.spec. nodeSelector 设 置 Node Selector， 可 以 只 在 匹配 的 
Node 上 运行 Daemon Pod。 


通过 定义 文件 创建 Daemon Set: 


$ kubectl create -f prometheus-node-exporter.yaml --validate=fals 


daemonset "prometheus-node-exporter" created 


$ kubectl get daemonset prometheus-node-exporter 
NAME CONTAINER(S) IMAGE(S) SEL 


prometheus-node-exporter C prom/prometheus daemon=p 


Daemon Set 创 建成 功 后 ， 将 在 所 有 Node 上 运行 Pod: 


$ kubectl get pods --selector daemon=prom-node-exp --output wide 


NAME READY STATUS RESTA 
prometheus-node-exporter-qpta1 1/1 Running 0 
prometheus-node-exporter -j04ks 1/1 Running 0 
prometheus-node-exporter -ss23x 1/1 Running 0 


当 删 除 Daemon Set 后 ， 相 关联 的 Pod 也 会 被 删除 : 


$ kubectl delete daemonset prometheus-node-exporter 


daemonset "prometheus-node-exporter" deleted 


$ kubectl get pods --selector daemon=prom-node-exp -0 wide 


NAME READY STATUS RESTARTS AGE NODE 


如 果 希 望 删除 Daemon Set 而 保留 关联 的 Po0d， 运 行 kubectl delete 时 加 
上 参数 --cascade=false 即 可 。 


12.2 ”Kubernetes 的 高 可 用 性 








高 可 用 性 是 一 个 老生 常 谈 的 话题 ， 当 然 是 因为 这 是 人 们 非常 关心 的 
特性 ， 它 决定 了 一 个 系统 的 最 终 价 值 。 在 生产 环境 中 ， 任 何 系 统 都 需要 
持续 可 靠 地 运行 ， 保 持 其 服务 的 高 度 可 用 性 ， 这 是 一 个 最 基本 的 要 求 。 
特别 是 对 于 Kubernetes 这 样 的 云 平 台 ， 一 个 将 要 承载 着 大 量 应 用 的 系 
统 ， 它 的 任何 故障 都 可 能 大 面积 地 影响 业务 ， 其 重要 性 自然 不 言 而 喻 。 


Kubernetes 属 于 典型 的 主 从 分 布 式 架构 ，Kubernetes 的 重要 数据 集中 
存储 在 Etcd， 数 据 层 的 可 靠 性 至 关 重 要 ， 对 Etcd 进 行 集群 化 是 必 不 可 少 
的 (可 参考 14.3.2 节 ) 。 


Kubernetes Node 作 为 Pod 的 运行 机 ， 原 生 文 持 集群 化 扩展 来 提供 容 
灾 容 错 能 力 。Kubernetes Node 运 行 后 将 会 注册 到 Kubernetes Master， 并 
定时 上 报 心跳 信息 以 说 明 其 可 用 。Kubernetes ”IMaster 调 度 Pod 到 可 用 的 
Kubernetes Node 部 署 运行 ， 如 果 有 Kubernetes Node Z Æ EHL, 
Kubernetes ”Master 会 将 该 Kubernetes ”Node 设置 为 不 可 用 状态 。 然 后 
Replication Controller 会 重新 创建 Pod， 从 而 调度 到 新 的 Kubernetes Node 
上 。 当 然 ，Kubernetes Node 的 数目 至 少 要 大 于 2 才 可 以 保障 Pod 的 高 可 用 
性 。 





在 Kubernetes ”Master 的 高 可 用 性 方案 中 需要 特别 注意 ，Kubernetes 
API ”Server 可 以 多 实例 运行 ， 而 Kubernetes Scheduler 和 Kubernetes 
Controller Manager 不 能 有 多 个 实例 同时 运行 。Kubernetes 官 方 提供 了 一 
种 方案 ， 如 图 12-1 所 示 。 
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图 12-1 Kubernetes 的 高 可 用 性 





在 这 个 方案 中 ，Kubernetes Master4 t KA, HEP Kubernetes API 
Server, Kubernetes Scheduler 和 Kubernetes Controller Manager 3 个 组 件 分 
别 作为 Static Pod 由 Kubelet 来 控制 管理 。Kubernetes API Server 可 以 在 每 
个 Kubernetes Master 节 点 上 运行 ， 前 端 通过 负载 均衡 器 作为 访问 入 口 。 





另外 ， 每 个 Kubernetes Master 节 点 上 需要 运行 一 个 小 程序 
Podmaster，Podmaster 通 过 Etcd 进 行 选 举 ， 从 多 个 Kubernetes Master} i 
择 主 节点 ， 只 有 主 节 点 上 会 运行 Kubernetes Scheduler 和 Kubernetes 


Controller Manager。 当 主 节 点 发 生 宕 机 时 ， 选 择 新 的 主 节点 运行 


Kubernetes Scheduler 和 Kubernetes Controller Manager。 


12.3 平台 监控 


监控 是 整个 运 维 环 节 ， 乃 至 整个 产品 生命 周期 中 最 重要 的 一 环 ， 事 
前 及 时 预警 发 现 故 障 ， 事 后 提供 翔实 的 数据 用 于 退 查 定位 问题 。 对 于 
Kubernetes 来 说 ， 监 控 的 层级 和 需求 是 多 样 的 ， 对 于 系统 管理 员 来 说 ， 
希望 Kubernetes 系 统 级 别 的 监控 ， 比 如 Node 的 资源 消耗 数据 用 来 判断 是 
售 需 要 增加 新 的 机 器 。 而 对 于 使 用 人 员 来 说， 和 希望 应 用 本 喘 监 控 ， 包 括 
Pod 或 者 容器 的 详细 运行 数据 ， 用 以 了 解 应 用 的 性 能 情况 和 施 贷 所 在 。 





Kubernetes 提 供 了 平台 监控 支持 ， 安 装 方法 可 参考 2.3.2 节 ， 收 集 
Kubernetes 各 个 维度 的 数据 ，Kubernetes 平 台 监 控 的 逻辑 设计 如 图 12-2 所 
示 。 





图 12-2 Kubernetes 平 台 监 控 


Kubernetes 平 台 监 控 的 两 个 关键 组 件 是 cAdvisor 和 Heapster。 


12.3.1 cAdvisor 


cAdvisor (Container Advisor) 是 谷歌 开源 的 一 个 容器 监控 工具 。 它 
是 一 个 守护 进程 ， 收 集 、 统 计 和 处 理 宿主 机 和 容器 的 数据 ， 包 括 实时 和 
历史 的 CPU、 内 存 、 人 磁盘、 网 络 使 用 情况 。 同 时 ，cAdvisor 提 供 民 好 的 
Web 界 面 和 Rest API 来 展示 数据 ， 帮 助 系统 管理 者 清楚 了 解 容 融 的 资源 
使 用 情况 和 运行 性 能 数据 。 





提示 


在 CAdvisor 的 认识 中 ， 容 塔 的 概念 是 广义 的 ， 不 仅仅 包括 Docker 
容器 ， 也 包括 其 他 容器 实现 ， 另 外 宿主 机 本 身 也 是 一 种 容器 ， 称 为 根 
容器 ， 它 是 一 种 原生 容器 。 








Web UI 





cAdvisor 提 供 了 一 个 Web 界 面 可 以 查询 监控 数据 ， 在 cAdvisor 运 行 
后 ， 便 可 以 访问 cAdvisor 的 Web 界 面 ， 如 图 12-3 所 示 。 
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图 12-3 cAdvisor Web 界 面 


REST API 


cAdvisor 提 供 REST API 用 于 获取 监控 数据 ，cAdvisor 的 REST API 访 


问 方式 为 http:// <hostname>:<port>/api/<version>/<request> . 


cAdvisor REST API 支 持 的 版 本 和 请 求 类 型 如 下 所 示 。 


。V1.0: 


evl1.l: 


evl.2: 


。V1.3: 


containers,machine 
containers,machine,subcontainers 
containers,docker,machine,subcontainers 
containers,docker,events,machine,subcontainers 


v2.0: 


appmetrics,attributes,events,machine,ps,spec,stats,storage,summary,version 


其 中 v1.3 是 最 新 的 稳定 版 本 ，v2.0 处 于 beta 阶 段 ， 有 具体 说 明 如 表 12-1 
所 示 。 


#12-1  cAdvisor REST API 


URL 说 明 

GET /api/v1.x/machine 获取 宿主 机 信息 

GET /api/v1.x/containers/<container> 获取 指定 容器 的 监控 数据 

GET /api/v1.x/subcontainers/<container> | 获取 指定 子 容 器 的 监控 数据 

GET /api/v1.x/docker 获取 所 有 Docker 容 器 的 监控 

GET /api/v1.x/docker/<container> 获取 指定 Docker 容 器 的 监控 数据 。 可 以 使 用 Docker 
容器 UUID 或 者 名 称 

GET /api/v1.x/events/<container> 获取 指定 容器 的 事件 信息 

GET /api/v2.X/version 获取 cAdvisor 的 版 本 

GET /api/v2.x/machine 获取 宿主 机 信息 

GET /api/v2.x/attributes 获取 宿主 机 的 硬件 和 软件 属性 

GET /api/v2.x/storage 获取 宿主 机 的 存储 设备 信息 

GET /api/v2.x/stats/<container> 获取 指定 容器 的 统计 数据 。 Docker 容 器 需要 增加 参数 
type=docker 

GET /api/v2.x/summary/<container> 获取 指定 容器 的 统计 汇总 数据 。 Docker 容 器 需要 增加 


























参数 type=docker 

GET /api/v2.x/spec/<container> 获取 指定 容器 的 规格 。Docker 容 器 需要 增加 参数 
type=docker 

GET /api/v2.x/ps/<container> 获取 指定 容器 包含 的 所 有 进程 信息 。 Docker 容 器 需要 
增加 参数 type=docker 

GET /api/v2.x/appmetrics/<container> 支持 自 定义 应 用 的 监控 维度 ， 通 过 API 获 取 监 控 数 据 














Kubelet 集 成 


Kubelet 组 件 已 经 集成 了 cAdvisor， 在 Kubernetes Node 上 可 以 直接 访 
问 cCAdvisor，cAdvisor 运 行 端 口 可 以 通过 Kubelet 的 局 动 参数 --cadvisor- 
port 设 置 ， 默 认 是 4194。 


Kubelet 基 于 cAdvisor 提 供 了 REST API (默认 端口 10255) 来 获取 
Node 和 Pod/ 容 右 的 监控 数据 。 


。 获 取 Node 的 监控 统计 数据 ， 如 表 12-2 所 示 。 


表 12-2 获取 Node 的 监控 统计 数据 





URL GET /stats/ 


num_stats: 返回 最 大 的 统计 数据 条 数 ， 默 认 值 
参数 为 60 
. start: 统计 的 起 始 时 间 ， 默 认 最 开始 的 时 间 
end: 统计 的 结束 时 间 ， 默 认 当前 时 间 





。 获 取 非 Kubernetes 容 器 的 监控 统计 数据 ， 如 表 12-3 所 示 。 


表 12-3 获取 非 Kubernetes 容 器 的 监控 统计 数据 





containerName: 需要 统计 的 容器 名 称 ， 默 认 值 


为 /> 

subcontainers: 是 否 包含 子 容器 ， 默 认 值 为 false 
参数 num_stats: 返回 最 大 的 统计 数据 条 数 ， 默 认 值 

为 60 


start: 统计 的 起 始 时 间 ， 默 认 最 开始 的 时 间 
end: 统计 的 结束 时 间 ， 默 认 当前 时 间 





。 获 取 Kubernetes 容 器 的 监控 统计 数据 ， 如 表 12-4 所 示 。 


表 12-4 获取 Kubernetes 容 器 的 监控 统计 数据 





GET /stats/<namespace>/<pod_name>/<container_name> 
URL | GET /stats/<pod_name>/<container_name> (查询 默认 
Namespace ) 





num_stats: 返回 最 大 的 统计 数据 条 数 ， 默 认 值 为 60 
参数 | start: 统计 的 起 始 时 间 ， 默 认 最 开始 的 时 间 
end: 统计 的 结束 时 间 ， 默 认 当 前 时 间 


Eee 


Kubelet 统 计 API 返 回 的 监控 统计 数据 的 格式 如 下 所 示 。 
e name: 容器 名 称 。 
e aliases: 容器 别名 。 


e namespace: 命名 空间 ， 由 cAdvisor 定 义 。 





。Subcontainers: 包含 的 子 容 右 列表 。 
espec: 容器 规格 ， 包 含 如 下 信息 。 


。creation_time: 创建 时 间 。 

e labels: 包含 的 标签 。 

。has_cpu: 是 否 有 CPU。 

。cpu: CPU 信 息 。 

。has_memory: 是 否 有 内 存 。 
。memory: 内 存 信息 。 
。has_network: 是 否 有 网 络 。 
。has_filesystem: 是 否 有 文件 系统 。 
“has_diskio: 是 否 有 磁盘 IO。 
“image: 容器 镜像 。 


e stats: 容器 监控 统计 数据 ， 每 条 数据 包含 如 下 信息 。 


e timestamp: F} MJÆR. 
e cpu: CPU 统计 数据 。 
e diskio: 磁盘 IO 统计 数据 。 
e memory: 内 存 统计 数据 。 


e network: 网 络 统计 数据 。 
e filesystem: 文件 系统 统计 数据 。 


。task_stats: 任务 统计 数据 。 


12.3.2 Heapster 





Heapster 是 谷歌 开源 的 容器 集群 的 监控 收集 工具 ， 它 可 以 集成 
Kubernetes 进 行 监控 数据 的 收集 汇总 ， 提 供 REST API 来 获取 Kubernetes 
各 个 维度 的 监控 数据 。 男 外 ，Heapster 支 持 对 接 第 三 方 系统 ， 将 监控 数 
据 导 入 到 第 三 方 系统 进行 进一步 处 理 。 





REST API 


Heapster 提 供 REST API， 如 表 12-5 所 示 。 


表 12-5 Heapster REST API 


URL 
GET /api/v 1/metric-export RE cit HS Metrics 
GET /api/v 1/metric-export-schema 甘 取 Metric 数 据 的 规格 
POST /api/v1/sinks LE 4 A AYSink 
GET /api/v I/sinks 取 当 前 的 Sink 





























集成 Kubernetes 


Heapster 在 与 Kubernetes 集 成 的 时 候 ，Heapster 调 用 Kubernetes API 获 
取 所 有 Node 列 表 ， 然 后 调用 Kubelet 的 API 收 集 汇 总 监控 数据 。 同 时 ， 
Heapster 根 据 收集 到 的 数据 建立 一 个 Kubernetes 监 探 模型 (Metric 
Model) ， 包 括 Kubernetes 以 下 层级 。 





e Cluster: 整个 Kubernetes 运 行 环 境 的 监控 模型 。 


" Node: 各 个 Node 的 监控 数据 模型 包括 机 器 本 里 的 监控 和 Node 上 
运行 的 Pod 的 监控 。 


e Namespace: 各 个 Namespace 监 探 模型， 相当 于 Namespace 下 所 有 
Pod 的 监控 。。Pod: 各 个 Pod 的 监控 模型 。 


e Container: 各 个 Container 监 控 模 型 。 


Kubernetes 监 控 模 型 提供 API 来 获取 各 个 层级 的 监控 数据 ， 如 表 12-6 
所 示 。 
表 12-6 Kubernetes 监控 模型 


层级 URL 
Cluster /api/v1/model/ 








/api/v1/model/metrics/ 
/api/v1/model/metrics/<metric-name> 
/api/v1/model/stats/ 
/api/v1/model/nodes/ 





/api/v1/model/nodes/<node-name>/ 





/api/v1/model/nodes/<node-name>/pods/ 
/api/v1/model/nodes/<node-name>/metrics/ 
/api/v1/model/nodes/<node-name>/metrics/<metric-name> 


/api/v1/model/nodes/<node-name>/stats/ 








续 表 
层级 URL 


Namespace | /api/v1/model/namespaces/ 








/api/v 1/model/namespaces/<namespace-name>/ 





/api/v 1/model/namespaces/<namespace-name>/metrics/ 





/api/v 1/model/namespaces/<namespace-name>/metrics/<metric-name> 





/api/v 1/model/namespaces/<namespace-name>/stats/ 


/api/v 1/model/namespaces/<namespace-name>/pods/ 





/api/v 1/model/namespaces/<namespace-name>/pods/{ pod-name }/ 





/api/v 1/model/namespaces/<namespace-name>/pods/{ pod-name }/metrics/ 





/api/v 1/model/namespaces/<namespace-name>/pods/<pod-name>/metrics/<metric-name> 





/api/v 1/model/namespaces/<namespace-name>/pods/<pod-name>/stats/ 





Container /api/v 1/model/namespaces/<namespace-name>/pods/<pod-name>/containers/ 


/api/v 1/model/namespaces/<namespace-name>/pods/<pod-name>/containers/<container-name>/ 





/api/v 1/model/namespaces/{ namespace-name }/pods/<pod-name>/containers/<container-name>/ 


metrics/ 





/api/v 1/model/namespaces/<namespace-name>/pods/<pod-name>/containers/<container-name>/ 
metrics/<metric-name> 
/api/v 1/model/namespaces/<namespace-name>/pods/<pod-name>/containers/<container-name>/ 


stats/ 


/api/y 1/model/nodes/<node-name>/freecontainers/ 





/api/v 1/model/nodes/<node-name>/freecontainers/<container-name>/ 





/api/v 1/model/nodes/<node-name>/freecontainers/<container-name>/metrics/ 





/api/v 1/model/nodes/{ node-name }/freecontainers/{ container-name }/metrics/{ metric-name } 





/api/v 1/model/nodes/{ node-name }/freecontainers/{ container-name } /stats/ 
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Kubernetes 提 供 了 平台 日 志 支 持 ， 安 装 方法 可 参考 2.3.3 节 。 平 台 日 
en Elasticsearch+Kibana， 其 中 Fluentd 作 为 Logging Agent 收 
集 日 志 汇 总 到 Elasticsearch。 


Fluentd 是 一 个 开源 的 日 志 收 集 系统 ， 文 持 150 多 个 插件 ， 能 够 将 日 
志 收 集 到 MongoDB、Redis、Amazon S3 和 Elasticsearch 等 ，Fluentd 能 够 
以 JSON 格 式 处 理 日 志 ， 具 备 每 天 收集 5000+ 台 服务 器 上 5TB 的 日 志 数 
据 ， 每 秒 处 理 50000 条 消息 的 性 能 。 


Fluentd 运 行 在 Kubernetes 的 所 有 节点 上 ， 收 集 Kubernetes 组 件 的 日 
志 ，Fluentd 的 配置 如 下 所 示 : 





<source> 
type tail 
format none 
path /var/log/docker.1og 
pos_file /var/log/es-docker.1log.pos 
tag docker 


</source> 


<source> 
type tail 
format none 
path /var/log/etcd.1og 
pos_file /var/log/es-etcd.1log.pos 
tag etcd 


</source> 


<source> 
type tail 
format none 
path /var/log/kubelet.log 
pos_file /var/log/es-kubelet.log.pos 
tag kubelet 


</source> 


<source> 
type tail 
format none 
path /var/log/kube-apiserver.log 
pos_file /var/log/es-kube-apiserver.log.pos 
tag kube-apiserver 


</source> 


<source> 
type tail 
format none 
path /var/log/kube-controller-manager.log 
pos_file /var/log/es-kube-controller-manager.log.pos 
tag kube-controller-manager 


</source> 


<source> 
type tail 
format none 
path /var/log/kube-scheduler.log 
pos_ file /var/log/es-kube-scheduler.log.pos 
tag kube-scheduler 


</source> 


Fluentd 配 置 中 的 Source 用 于 指定 日 志 输 入 资源 ， 其 中 字段 含义 如 下 
所 示 。 





。 type: 指定 日 志 的 输入 方式 ， 其 中 tail 方 式 是 不 停 地 从 源 文 件 中 获 
取 新 的 日 志 。 


e format: 指定 日 志 的 输出 格式 。 
。path: 指定 日 志文 件 的 位 置 。 
stag: 指定 日 志 tag， 用 来 对 不 同 的 日 志 进 行 分 类 。 


可 以 看 出 ，Fluentd 将 监控 每 个 组 件 的 日 志文 件 ， 然 后 设置 上 tag， 
最 后 输出 。 男 外 ，Fluentd 同 时 会 监控 容器 的 日 志文 件 : 


<source> 
type tail 
path /var/log/containers/*.log 
pos_ file /var/log/es-containers.log.pos 
time_format %Y-%M-%AT%H :%M :%S 
tag kubernetes. * 
format json 
read_from_head true 


</source> 


Fluentd 会 监控 /var/log/containers 目 录 下 的 所 有 日 志文 件 ， 然 后 以 
JSON 格 式 输出 ， 其 中 设置 的 tag 是 kubernetes.*， 在 tail 方 式 下 会 被 设置 为 
kubernetes.path.to.file。 


实际 上 ，/vVar/log/containers 目 录 是 由 Kubelet 组 件 创建 的 ，Kubelet 在 
其 中 建 并 Pod 的 容器 日 志文 件 ， 这 些 是 容器 中 应 用 打印 到 标准 输出 
(Stdout) 的 日 志 ， 即 通过 kubectl logs 或 者 docker logs 查 询 到 的 日 志 。 


比如 我 们 运行 的 Hello World Pod， 其 信息 查询 如 下 : 


$ kubectl describe pod hello-world 
Name: hello-world 

Namespace: default 

Image(s): ubuntu:14.04 

Node: kube-node-2/192.168.3.148 


Start Time: Fri, 04 Dec 2015 19:28:21 +0800 


Labels: <none> 
Status: Succeeded 
Reason: 

Message: 

IP: 


Replication Controllers:<none> 
Containers: 
hello: 
Container ID: 
docker ://8c9df43b96227d14f8665d87d5b32ee39ce11328bd1d1848465c3c9 
Image: ubuntu:14.04 
Image ID: 
docker ://8251da35e7a79dca688682f 6da6148a06d358c6F094020844468a78 
State: Terminated 
Reason: Error 
Exit Code: 0 
Started: Fri, 04 Dec 2015 19:28:28 +0800 
Finished: Fri, 04 Dec 2015 19:28:29 +0800 


Ready: False 


Restart Count: 0 
Environment Variables: 


Hello World Pod 包 含 的 一 个 容器 hello 将 输出 Hello World， 这 条 输出 
日 志 实 际 上 是 由 Docker 进 行 存 储 ， 并 通过 Kubernetes 获 取 的 ， 而 Fluentd 
将 会 进 行 日 志 stu 收集 o 


$ kubectl logs hello-world hello 
Hello world 





Docker 容 器 的 日 志 都 会 由 Docker 进 行 存 储 ， 而 Kubelet 会 
在 /var/log/containers 下 生成 一 个 文件 软 连接 Docker 存 储 的 容器 日 志文 
件 ， 文 件 格式 是 [pod_name]_[namespace]_ [container_name]- 


[container_id].log: 


$ cat hello-world default_hello-8c9df43b96227d14f8665d87d5b32ee39 


{"log":"Hello World\n", "stream": "stdout", "time":"2015-12-04T11: 28 
那么 Fluentd 将 读 取 这 个 日 志文 件 ， 对 应 的 tag 是 : 
kubernetes.var.log.containers.hello-world default_hello-8c9df43b9 


Fluentd 最 终 将 日 志 导 入 到 Elasticsearch， 通 过 检索 Elasticsearch 可 以 
查询 到 1 该 日 志 Iù s 





{ 
"_index": "logstash-2015.12.04", 
"_type": "fluentd", 


"_id": "AVFSOtILXx_4Q0Dgz43x", 


"” Score": 6.7633038, 
"source": { 
"log": "Hello World\n", 
"stream": "stdout", 
"docker": { 


"Container_id": "8c9df43b96227d14f8665d87d5b32ee39ce11328 


ty 

"kubernetes": { 
"namespace": "default", 
"pod_name": "hello-world", 
"container_name": "hello" 

ty 

"tag": 


"kubernetes.var.log.containers.hello-world_default_hello-8c9df43b 
9ce11328bd1d1848465c3c9e97a09b8a. log", 
"@timestamp": "2015-12-04T11:28:29+00:00" 


12.542 ise 


Kubernetes 系 统 在 长 时 间 运 行 后 ，Kubernetes ”Node 会 下 载 非 常 多 的 
镜像 ， 其 中 可 能 会 存在 很 多 过 期 的 镜像 。 同 时 因为 运行 大 量 的 容器 ， 容 
器 退出 后 就 变 成 死亡 容器 ， 将 数据 残留 在 宿主 机 上 ， 这 样 一 来 ， 过 期 镜 
像 和 死亡 容器 都 会 占用 大 量 的 硬盘 空间 。 如 果 硬 盘 空 间 被 用 光 ， 可 能 会 
发 生 非 常 糟糕 的 情况 ， 甚 至 会 导致 硬盘 的 损坏 。 为 此 ，Kubelet 会 进行 垃 











圾 清理 工作 ， 即 定期 清理 过 期 镜像 和 死亡 容器 。 
12.5.1 镜像 清理 


镜像 清理 的 集 略 是 当 人 硬盘 空间 使 用 紊 超过 立 值 的 时 候 开 始 执行 ， 
Kubelet 执 行 清理 的 时 候 优先 清理 最 久 没 有 被 使 用 的 镜像 。 


人 硬盘 空间 使 用 率 的 阔 值 通过 Kubelet 的 启动 参数 --image-gc-high- 
threshold 和 --image-gc- low-threshold 指 定 。 


12.5.2 容器 清理 


Kubelet 容 右 消 理 的 相关 参数 如 表 12-7 所 示 。 


表 12-7 Kubelet 容 器 清理 参数 





参数 Kubelet 启 动 参数 | 说 明 


死亡 容器 能 够 被 删除 








MinAge --minimum-container- 的 最 小 TTL， 默 认 是 
ttl-duration A 
1 分 钟 
--maximum-dead- 每 个 Pod 人 允许 存 在 的 
MaxPerPodContainer | containers-per- 最 大 死亡 容器 数目 ， 
container PRED 
; 允许 存在 的 最 大 死亡 
T -d d- BY HA Ww 、 
MaxContainers ee oe 容器 数目 ， 默 认 是 


containers 
100 





Kubelet 定 时 执行 容器 清理 ， 每 次 根据 以 上 3 个 参数 选择 死亡 容器 市 
除 ， 通 常情 况 下 优先 删除 创建 时 间 最 久 的 死亡 容器 。Kubelet 不 会 删除 非 
Kubelet 管 理 的 容器 。 


12.6 ”Kubernetes 的 Web 界 面 


Kubernetes 提 供 了 一 个 web 界面 Kube 
UI Chttps://github.com/kubernetes/kube-ui) ， 用 来 图 形 化 展示 运行 环境 
信息 。 安 装 方法 可 参考 2.3.4 节 。 安 装 成 功 后 可 以 通过 Kubernetes API 
Server 的 接口 http://<kubernetes-master>/ui 进 行 访问 。 


Kube UI 首页 图 形 化 展示 了 所 有 Kubernetes Node 的 资源 使 用 情况 ， 
包括 CPU、Memory 和 Filesystem 的 使 用 情况 ， 如 图 12-4 所 示 。 














图 12-4 Kube UIJ H 


单 击 首页 右上 角 的 View 按 钮 ， 包 含 Explore、Pods、Nodes、 
Replication ”Controllers、Services 和 Events 等 选项 。 单 击 进 入 Explore 页 
面 ， 会 列 出 所 有 Pod、Replication ”Controller 和 Service， 支 持 筛 选 和 排列 


展示 ， 如 图 12-5 所 示 。 














图 12-5 Explore 页面 


同时 可 以 分 别 查询 Pod、Replication ”Controller 和 Service 的 详细 信 
恩 ， 比 如 查询 Service 的 详细 信息 ， 如 图 12-6 所 示 。 





Service: nginx 
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图 12-6 查询 Service 的 详细 信息 


其 他 页 面 也 列 出 了 相应 的 信息 ， 比 如 查询 Event， 如 图 12-7 所 示 。 
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图 12-7 #74 Event 





Kube UI 只 能 简单 地 查看 一 些 信 息 ， 不 能 进行 修改 ， 新 的 Kubemetes 
Dashboard (https://github.com/kubernetes/dashboard〉 正 在 开发 中 ， 将 支 
持 功能 更 加 强大 的 Web 界 面 。 
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第 13 章 
CoreOS 


CoreOS 是 容器 生态 圈 重 要 的 一 环 ， 与 Kubernetes 和 Docker 都 有 着 非 
党 密切 的 关系 。 本 章 将 简单 介绍 CoreOS， 然 后 讲解 如 何 安 装 CoreOS， 


一 /一 


以 及 如 何 使 用 CoreOS 运 行 Kubernetes。 





13.1 CoreOS 介 绍 


CoreOS 是 一 个 轻 量 级 、 容 器 化 的 Linux 发 行 版 ， 借 助 了 以 Docker 为 
代表 的 容器 技术 ， 专 为 大 型 数据 中 心 而 设计 ， 旨 在 通过 轻 量 的 系统 架构 
和 有 灵活 的 应 用 程序 部 署 能 力 简 化 数据 中 心 的 维护 成 本 和 复杂 度 。 





CoreOS 没 有 提供 包 管 理工 具 ， 是 通过 容 吉 化 的 运算 环境 癌 应 用 程 
序 提供 运算 资源 的 。 在 CoreOS 中 ， 所 有 应 用 程序 都 被 装 在 容器 中 运行 
在 操作 系统 之 上 ， 可 以 很 轻松 地 将 应 用 程序 在 操作 系统 之 间 转 移 。 





应 用 程序 之 间 共 至 系统 内 核 和 资源 ， 但 是 彼此 之 间 又 互 不 可 见 。 这 
意味 着 应 用 程序 将 不 会 再 个 直 接 安 装 到 操作 系统 中 ， 而 是 运行 在 容 右 
中 。 这 种 方式 使 得 操作 系统 、 应 用 程序 及 运行 环境 之 间 的 耘 合 度 大 大 降 
低 。 相 对 于 传统 的 部 车 方式 而 言 ， 在 CoreOS 集 群 中 部 效应 用 程序 更 加 
灵活 便捷 ， 应 用 程序 运行 环境 之 间 的 干扰 更 少 ， 而 且 操 作 系统 自身 的 维 
护 也 更 加 容易 。 




















借助 容器 的 能 力 ，CoreOS 可 以 剔除 任何 不 必要 的 软件 和 服务 ， 最 





小 化 定制 化 Linux 系 统 。 因 此 很 小 很 轻 量 ， 管 理 员 操心 的 事情 会 少 很 
多 ， 人 允许 快速 修复 ， 占 据 的 空间 也 很 小 。 








在 一 定 程 度 上 减轻 了 维护 一 个 服务 器 集群 的 复杂 度 ， 可 帮助 用 户 从 
烦琐 的 系统 及 软件 维护 工作 中 解脱 出 来 。 


13.2 CoreOS 工 具 链 


13.2.1 Etcd 


在 CoreOS 集 群 中 处 于 骨架 地 位 的 是 Etcd，Etcd 是 Core 团 队 开 发 的 一 
个 高 可 用 的 键 值 存储 系统 ， 灵 感 来 自 于 ZooKeeper 和 Doozer。Etcd 以 默 
认 的 形式 安装 于 每 个 CoreOS 系 统 之 中 ，CoreOS 集 群 中 的 程序 和 服务 可 
以 通过 Etcd 共 享 信息 或 服务 发 现 。 


13.2.2 Flannel 


Flannel 是 CoreOS 团 队 开 发 的 履 盖 网 络 工 具 ，CoreOS 集 群 使 用 
Flannel 创 建 的 一 个 容器 履 盖 网络， 实现 容器 之 间 的 通信 报 文 ， 实 现 跨 主 
机 通信 。 


13.2.3 Rocket 


Rocket 是 CoreOS 推 出 的 一 款 容 器 引擎 ， 和 Docker 类 似 ， 帮 助 开 发 者 
打包 应 用 和 依赖 包 到 可 移植 容 堪 中 ， 简 化 搭建 环境 等 部 署 工 作 。Rocket 
同 Docker 相 比 更 加 专注 于 容 右 核心 技术 和 容器 标准 。 


13.2.4 Systemd 


Systemd 是 Linux 下 的 一 种 Init 软 件 ， 由 Lennart Poettering 带 头 开发 ， 
并 在 LGPL 2.1 及 其 后 续 版 本 许可 证 下 开源 发 布 框架 以 表示 系统 服务 间 的 
依赖 关系， 并 依 此 实现 系统 初始 化 时 服务 的 并 行 启 动 ， 同 时 达到 降低 
Shell 的 系统 开销 的 效果 ， 最 终 代 葵 现 在 常用 的 System V 与 BSD 风 格 的 
Init 程 序 ，CoreOS 已 将 Systemd 作 为 Linux 发 行 版 的 Init 系 统 。 


13.2.5 Fleet 


Fleet 是 一 个 通过 Systemd 对 CoreOS 集 群 进行 控制 和 管理 的 工具 。 
Fleet 与 Systemd 之 间 通 过 D-Bus ”API 进行 交互 ， 每 个 FleetAgent 之 间 通 过 
Etcd 服 务 来 注册 和 同步 数据 。Fleet 提 供 的 功能 非常 丰富 ， 包 括 人 查看 集群 
中 服务 器 的 状态 、 启 动 或 终止 Docker 容 器 、 读 取 日 志 内 容 等 。 更 为 重要 
的 是 ，Fleet 可 以 确保 集群 中 的 服务 一 直 处 于 可 用 状态 。 当 出 现 某 个 通过 
Fleet 创 建 的 服务 在 集群 中 不 可 用 时 ， 如 由 于 某 台 主机 因为 硬件 或 网 络 故 
障 从 集群 中 脱离 时 ， 原 本 运行 在 这 台 服 务 器 中 的 一 系列 服务 将 通过 Fleet 
被 重新 分 配 到 其 他 可 用 服务 器 中 。 虽 然 当前 Fleet 还 处 于 初期 状态 ， 但 是 
其 管理 CoreOS 集 群 的 能 力 是 非常 有 效 的 ， 并 且 仍 然 有 很 大 的 扩展 空 
间 ， 目 前 已 提供 简单 的 API 接 口供 用 户 集 成 。 





13.3 “CoreOS 实 上 践 


13.3.1 安装 CoreOS 

本 节 将 使 用 Vagrant 部 署 CoreOS， 这 可 以 说 是 最 简单 的 方式 了 ， 可 
以 使 用 本 地 虚拟 机 快速 部 署 CoreOS。 
准备 工作 

在 机 器 上 预先 装 好 VirtualBox 和 Vagrant: 

。VirtualBox 4.3.10 以 上 版 本 

。Vagrant 1.6 以 上 版 本 


下 载 CoreOS-Vagrant 仓 库 ， 其 中 包含 使 用 Vagrant 部 车 CoreOS 的 配 
置 文 件 : 


$ git clone https://github.com/coreos/coreos-vagrant 


$ cd coreos-vagrant 


配置 


在 CoreOS-Vagrant 仓 库 目 录 下 ，config.rb.sample 和 user-data.sample 
是 两 个 模板 文件 ， 根 据 这 两 个 模板 文件 可 以 对 CoreOS 部 署 进行 自 定义 
配置 ， 通 过 模板 文件 生成 配置 文件 : 


$ cp config.rb.sample config.rb 


$ cp user-data.sample user-data 


配置 文件 user-data 将 作为 CoreOS 操 作 系 统 初 始 化 时 使 用 的 Cloud-Init 
配置 文件 ，Cloud-Init 是 专 为 云 环境 中 虚拟 机 而 开发 的 工具 ， 所 根据 配置 
文件 对 虚拟 机 进行 系统 初始 化 配置 ， 配 置 文件 使 用 YAML 文 件 格 式 ， 并 


且 需 要 包含 此 loud-config: 








#cloud-config 
coreos: 
etcd2: 
#generate a new token for each unique cluster from https://di 
#discovery: https://discovery.etcd.io/<token> 
# multi-region and multi-cloud deployments need to use $publi 
advertise-client-urls: http://$public_ipv4:2379 
initial-advertise-peer-urls: http://$private_ipv4:2380 
# listen on both the official ports and the legacy ports 
# legacy ports can be omitted if your application doesn't dep 
listen-client-urls: http://0.0.0.0:2379,http://0.0.0.0:4001 
listen-peer-urls: http://$private_ipv4:2380,http://$private_i 
fleet: 
public-ip: $public_ipv4 
flannel: 
interface: $public_ipv4 
units: 
- name: etcd2.service 
command: start 


- name: fleet.service 


command: start 
- name: flanneld.service 
drop-ins: 
- name: 50-network-config.conf 
content: | 
[Service] 
ExecStartPre=/usr/bin/etcdctl set /coreos.com/network/c 
"10.1.0.0/16" }' 
command: start 
- name: docker-tcp.socket 
command: start 
enable: true 
content: | 
[Unit] 


Description=Docker Socket for the API 


[Socket] 
ListenStream=2375 
Service=docker.service 
BindIPv60nly=both 
[Install] 


WantedBy=sockets.target 


Cloud-Init 配 置 文件 中 包含 了 Etcd、Fleet、Flannel 和 Docker 的 服务 启 
动 参数 ， 其 中 使 用 两 个 变量 $private_ipv4 和 $public_ipv4， 它 们 会 在 实际 
运行 的 时 候 被 自动 玲 换 为 虚拟 机 的 真实 外 网 IP 和 内 网 IP 地 址 。 用 户 可 以 
根据 需要 ， 在 配置 中 添加 更 多 定制 化 的 服务 和 配置 ， 有 具体 信息 可 参考 








https://coreos.com/docs/cluster-management/setup/cloudinit-cloud-config 。 


另外 ，CoreOS 集 群 是 用 Etcd 进 行 服务 发 现 的 ，Cloud-Init 配 置 文件 
中 的 .coreos.etcd2. discovery 就 是 用 来 配置 一 个 外 部 Etcd 服 务 的 URL， 
CoreOS 启 动 时 通过 这 个 集群 标识 URL 地 址 自动 进入 同一 个 集群 中 ， 这 
就 实现 了 无 顷 人 工 干 预 的 集群 服务 器 自发 现 。 我 们 可 以 通过 Etcd 发 现 服 
务 (discovery.etcd.io) 申请 创建 URL， 如 果 没 有 配置 的 话 ， 在 config.rb 
中 也 会 自动 申请 创建 进行 配置 。 





配置 文件 config.rb 中 包含 了 Vagrant 虚 拟 机 的 配置 ， 通 过 这 个 文件 可 
以 履 辣 Vagrantfile 里 的 参数 。 我 们 主要 关注 $num_instances 和 
$update_channel 这 两 个 参数 : 


。 $num_instances 表 示 将 启动 的 CoreOS 集 群 中 需要 包含 主机 实例 的 
数量 。 


。 $update_channel 表 示 启 动 的 CoreOS 实 例 使 用 的 升级 通道 ， 可 以 是 
stable 、eta 或 alpha。 





现在 配置 config.rb， 将 部 署 有 1 个 节点 的 CoreOS 集 群 ， 并 使 用 alpha 
升级 通道 : 


$num_instances=1 


$update_channel='alpha' 


Her 


使 用 Vagrant 部 署 CoreOS: 


$ vagrant up 


Mie MDa, PY AWELE: 


$ vagrant status 


Current machine states: 


core-01 running (virtualbox) 
core-02 running (virtualbox) 
core-03 running (virtualbox) 


This environment represents multiple VMs. The VMs are all listed 
above with their current state. For more information about a spec 


VM, run “vagrant status NAME . 


在 CoreOS 集群 运行 后 ， 集 群 的 实例 之 间 通 过 Etcd 实现 自发 现 服 
务 ， 同 时 运行 起 Docker 和 Flannel， 形 成 连通 的 容器 集群 ， 可 以 SSH 到 
CoreOS 节 点 中 : 


$ vagrant ssh core-01 


然后 在 CoreOS 节 点 中 查询 服务 状态 : 


$ sudo systemctl status etcd2 docker flanneld 


13.3.2 4% H CoreOSiz 47 Kubernetes 


Kubernetes 是 一 个 容器 集群 管理 平台 ， 而 CoreOS 是 基于 容器 的 集群 
操作 系统 ， 两 者 可 以 说 有 着 干 丝 万 缕 的 关系 。CoreOS5 集 群 已 经 原生 运 


行 Docker， 同 时 使 用 Flannel 搭 建 出 容器 的 履 盖 网 络 ， 因 此 Kubernetes 非 
常 适合 运行 在 CoreOS 之 上 。 





现在 运行 3 个 节点 的 CoreOS 集 群 ， 我 们 将 在 CoreOS 集 群 之 上 运行 
Kubernetes， 其 中 所 有 节点 将 作为 Kubernetes Node， 而 节点 core-01 同 时 
作为 Kubernetes Master。 


启动 Kubelet 


CoreOS 在 alpha 开 发 版 “773.1.0 以 后 版 本 〉 中 集成 了 Kubernetes 的 核 
心 组 件 Kubelet， 我 们 通过 在 所 有 节点 中 进行 简单 配置 就 可 以 启动 
kubelet， 从 而 作为 Kubernetes Node。 








创建 kubelet Systemd 单 元 文件 /etc/systemd/system/kubelet.service: 


[Unit] 
Description=Kubernetes Kubelet 


Documentation=https://github.com/kubernetes/kubernetes 


[Service ] 

ExecStartPre=/usr/bin/mkdir -p /etc/kubernetes/manifests 
ExecStart=/usr/bin/kubelet \ 
--api-servers=http://kuber-apiserver:8080 \ 
--allow-privileged=true \ 
--config=/etc/kubernetes/manifests \ 

--V=2 

Restart=on-failure 


RestartSec=5 


[Install] 


WantedBy=multi-user.target :qw 


其 中 ， 我 们 将 在 节点 core-01 上 运行 Kubernetes API Server， 所 以 -- 
api-servers 设置 的 URL 指 同 core-01。 


配置 好 Systemd 单 元 文件 后 ， 使 用 systemctl 命 令 启 动 Kubelet: 


$ sudo systemctl daemon-reload 


$ sudo systemctl start kubelet 


Ae 


运行 后 用 Systemct 命 令 查 询 Kubelet 是 否 运 行 : 
$ sudo systemctl status kubelet 

另外 设置 kubelet 为 开机 自 启动 : 
$ sudo systemctl enable kubelet 
“= Kubernetes Master 


现在 在 节点 core-01 上 运行 Kubernetes Master, 46 Ff 4{Kubernetes 
Master 的 Pod 定 义 文 件 : 


$ wget https://raw.githubusercontent.com/coreos/pods/master/kuber 


然后 将 其 放 入 Kubelet 的 Manifest 目 录 ， 由 Kubelet 以 Daemon Pod 的 形 
式 运行 Kubernetes Master 各 组 件 : 


$ sudo cp kubernetes.yaml /etc/kubernetes/manifests/ 


确保 镜像 下 载 正常 ， 那 么 一 段 时 间 后 ，Kubernetes ”Master 的 各 个 组 
件 将 运行 起 来 。 


第 14 章 
Etcd 


Kubernetes 使 用 Etcd 进 行 存 储 ， 理 解 和 掌握 Etcd 对 于 管理 Kubernetes 
至 关 重 要 。 本 章 将 介绍 Etcd， 包 括 基 本 概念 和 绪 构 组 织 ， 然 后 详细 说 明 


如 何 运 行 和 管理 Etcd。 


14.1 Etcd 介 绍 


Etcd 是 一 个 高 可 用 的 键 值 存储 系统 ，Etcd 的 灵感 来 和 目 于 ZooKeeper 和 
Doozer， 通 过 Raft 共 识 算法 (The Raft Consensus Algorithm) 处 理 日 志 复 
制 以 保证 强 一 致 性 。 


Etcd 中 的 主要 概念 如 下 所 示 。 
。Raft: Etcd 所 采用 的 保证 分 布 式 系统 强 一 致 性 的 算法 。 
。Node: 一 个 Raft 状 态 机 实例 。 


。Member: 一 个 Etcd 实 例 ， 它 管理 着 一 个 Node， 并 且 可 以 为 客户 端 
请 求 提 供 服务 。。 Cluster: 由 多 个 Member 构 成 可 以 协同 工作 的 Etcd 集 
HE 


e Peer: 对 同一 个 Etcd 集 群 中 另外 一 个 Member 的 称呼 。 


e Client: 回 Etcd 集 群发 送 HTTP 请 求 的 客户 端 。 


“WAL: 预 写 式 日 志 ，Etcd 用 于 持久 化 存储 的 日 志 格 式 。 


Snapshot: Etcd 防 止 WAL 文 件 过 多 而 设置 的 快照 ， 存 储 Etcd 数 据 
状态 。 


。Proxy: Etcd 的 一 种 模式 ， 为 Etcd 集 群 提供 反 回 代理 服务 。 
e Leader: Raft 算 法 中 通过 竞选 而 产生 的 处 理 所 有 数据 提交 的 节点 。 


。Follower: 竞选 失败 的 节点 作为 Raft 中 的 从 属 节 点 ， 为 算法 提供 强 
一 致 性 保证 。 


e Candidate: 当 Follower 超 过 一 定时 间接 收 不 到 Leader 的 心跳 时 转变 
为 Candidate 开 始 竞选 。 


Term: 某 个 布点 成 为 Leader 到 下 一 次 竞选 的 时 间 ， 称 为 一 个 


Term. 


e Index: 数据 项 编号 。Raft 中 通过 Term 和 Index 来 定位 数据 。 


14.2 ”Etcd 的 结构 


Etcd 主 要 分 为 4 个 部 分 ， 如 图 14-1 所 示 。 


HTTP Server 


Entry 


Snapshot 





图 14-1 Etcd 的 结构 


。 HTTP Server: 用 于 处 理 用 户 发 送 的 API 请 求 以 及 其 他 Etcd 节 点 的 
同步 与 心跳 信息 请 求 。 


。 Store: 用 于 处 理 Etcd 文 持 的 各 类 功能 的 事务 ， 包 括 数据 索引 、 节 
点 状态 变更 、 监 控 与 反馈 、 事 件 处 理 与 执行 等 ， 是 Etcd 对 用 户 提 供 的 大 
多 数 API 功 能 的 具体 实现 。 





。Raft: 强 一 致 性 算法 的 具体 实现 ， 是 Etcd 的 核心 。 


。 WAL: Write Ahead Log〔 预 写 式 日 志 ) ， 是 Etcd 的 数据 存储 方 
式 ， 是 用 于 同系 统 提 供 原子 性 和 持久 性 的 一 系列 技术 。 在 使 用 WAL 的 
时 候 ， 所 有 的 修改 在 提交 之 前 都 要 先 写 入 日 志文 件 中 。Etcd 的 WAL 由 日 
志 存 储 与 快照 存储 两 部 分 组 成 ， 其 中 ，Entry 负 员 存 储 具 体 日 志 的 内 
容 ， 而 Snapshot 负 责 在 日 志 内 容 发 生变 化 的 时 候 保 存 Raft 的 状态 。WAL 





会 在 本 地 磁盘 的 一 个 指定 目录 下 分 别 存 放 日 志 条 目 与 快照 内 容 。 





通常 ， 一 个 用 户 的 请 求 发 送 过 来 ， 会 经 由 HTTP Server 转 发 给 Store 
进行 具体 的 事务 处 理 。 如 果 涉 及 节点 的 修改 ， 则 交 给 Raft 模 块 进行 状态 
的 变更 、 日 志 的 记录 ， 然 后 再 同步 给 其 他 Etcd 市 点 以 确认 数据 提交 ， 最 
后 进行 数据 的 提交 、 再 次 同步 。 





Etcd 属 于 分 布 式 架 构 ， 其 中 的 通信 模型 有 两 种 ， 一 种 是 Etcd Client 
同 Etcd Server 之 间 的 通信 ， 另 一 种 是 Etcd Peer 之 间 的 通信 。 


14.2.1 Client-to-Server 


在 默认 设置 下 ，Etcd 通 过 主机 的 2379/4001 端 口 向 Client 提 供 服务 ， 
每 个 主机 上 的 应 用 程序 都 可 以 通过 主机 的 2379/4001 端 口 以 HTTP + 
JSON 的 方式 向 Etcd 读 写 数据 。 写 入 的 数据 会 由 Etcd 同 步 到 集群 的 其 他 节 
点 中 ， 如 图 14-2 所 示 。 





etcd 


CLient CLient WAL 


CLient 























图 14-2 Etcd Client 同 Etcd Server 之 间 的 通信 


14.2.2 Peer-to-Peer 


在 默认 设置 下 ，Etcd 通 过 主机 的 2380/7001 端 口 在 各 个 节点 中 同步 
Raft 状 态 及 数据 ， 如 图 14-3 所 示 。 
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图 14-3 Etcd Peer 之 间 的 通信 


14.3 ”Etcd 实 践 


14.3.1 运行 Etcd 


可 以 从 Github 上 下 载 指定 版 本 的 Etcd 友 布 包 进行 安装 : 


$ wget https://github.com/coreos/etcd/releases/download/v2.2.0/et 
$ cd etcd-v2.2.0-linux-amd64 
$ cp ./etcd /usr/bin 


局 动 单 节 点 的 Etcd: 


$ etcd -name etcd \ 

-data-dir /var/lib/etcd \ 

-listen-client-urls http://0.0.0.0:2379,http://0.0.0.0:4001 \ 
-advertise-client-urls http://0.0.0.0:2379,http://0.0.0.0:4001 


在 Etcd 的 启动 参数 中 ，-name 设 置 Etcd 节 点 的 名 称 ，-data-dir 设 置 
Etcd 的 数据 目录 。 男 外 ，-listen-client-urls 设 置 了 Etcd 向 Client 提 供 服务 的 
监听 URL， 多 个 URL 直 接 用 逗号 分 隔 ， 而 -advertise-client-urls 指 定 了 Etcd 
对 外 广播 的 URL， 需 要 在 -listen-client-urls 配 置 URL 范 围 。 





14.3.2 ”Etcd 和 集群 化 


Etcd 和 集群 的 工作 原理 基于 Raft 共 识 算法 。Raft 共 识 算法 的 优点 在 
于 ， 可 以 在 高 效 地 解决 分 布 式 系统 中 各 个 节点 日 志 内 容 一 致 性 问题 的 同 
时 ， 也 使 得 集群 具备 一 定 的 容错 能 力 ， 即 使 集群 中 出 现 部 分 市 点 故障 、 
网 络 故障 等 问题 ， 仍 可 保证 其 余 大 多 数 节 点 正确 地 步 进 ， 甚 至 当 更 多 的 
节点 《一 般 来 说 超过 集群 节点 总 数 的 一 半 ) 出现 故障 而 导致 集群 不 可 用 
时 ， 依 然 可 以 保证 市 点 中 的 数据 不 会 出 现 错误 的 结 








因为 需要 选举 Leader 节 点 ， 所 以 Etcd 集 群 至 少 需 要 两 个 节点 ， 但 是 
如 果 是 两 个 成 员 ， 那 么 在 一 台 无 法 正常 运转 的 情况 下 ， 剩 下 的 一 个 也 无 
法 正常 工作 ， 一 般 建 议 是 3~9 个 节点 ， 并 且 一 个 重要 的 集群 优化 策略 是 
要 保障 集群 中 活跃 节点 的 数目 始终 为 奇数 个 。 


14.3.2.1 搭建 集群 


要 搭建 Etcd 集 群 ， 需 要 让 Etcd 节 点 互相 发 现 ， 目 前 提供 的 发 现 方式 
有 3 种 : 


。 静态 发 现 
。Etcd 动 态 发 现 


。DNS 服 务 发 现 


现在 我 们 通过 搭建 3 个 节点 的 Etcd 和 集群， 如 表 14-1 所 示 ， 分 别 介 绍 3 
种 方式 的 配置 方法 。 


表 14-1 Etcd 和 集群 环境 


所 主机 名 IP 
Etcd1 etcd1.example.com 192.168.3.140 
Etcd2 etcd2.example.com 192.168.3.141 
Etcd3 etcd3.example.com 192.168.3.142 


静态 服务 发 现 是 最 简单 的 一 种 搭建 方式 ， 这 要 求 事 先知 道 Etcd 集 群 
的 数目 以 及 每 个 节点 的 地 址 ， 然 后 在 每 个 Etcd 节 点 静态 地 配置 初始 的 
Etcd 和 集群 信息 : 








-initial-cluster etcdi=http://192.168.3.140:2380,etcd2=http://192 


-initial-cluster-state new 


其 中 ，-initial-cluster-state=new 表 示 这 是 在 从 无 到 有 搭建 Etcd 集 群 。 
参数 -initial-cluster 描 述 了 这 个 新 集群 中 共有 哪些 节点 ， 其 中 每 个 节点 用 





name=url 的 形式 描述 ， 节 点 之 间 用 有 去 号 分 隔 ， 并 且 指 定 的 UREL 是 Etcd 的 
广播 Peer 地 址 ， 即 需要 和 --initial-advertise-peer-urls 参 数 设 置 得 一 致 。 





分 别 在 3 个 节点 上 启动 Etcd: 
e Etcdl 


$ etcd -name etcd1 \ 

-data-dir /var/lib/etcd1i \ 

-listen-peer-urls http://192.168.3.140:2380 \ 
-initial-advertise-peer-urls http://192.168.3.140:2380 \ 
-listen-client-urls http://192.168.3.140:2379,http://127.0.0.1:23 
-advertise-client-urls http://192.168.3.140:2379 \ 
-initial-cluster 

etcdi=http://192.168.3.140:2380, etcd2=http://192.168.3.141:2380,e 
2:2380 \ 


-initial-cluster-state new 


e Etcd2 


$ etcd -name etcd2 \ 

-data-dir /var/lib/etcd2 \ 

-listen-peer-urls http://192.168.3.141:2380 \ 
-initial-advertise-peer-urls http://192.168.3.141:2380 \ 
-listen-client-urls http://192.168.3.141:2379,http://127.0.0.1:23 
-advertise-client-urls http://192.168.3.141:2379 \ 
-initial-cluster etcd1i=http://192.168.3.140:2380, etcd2=http://192 


-initial-cluster-state new 


。 Etcd3 


$ etcd -name etcd3 \ 

-data-dir /var/lib/etcd3 \ 

-listen-peer-urls http://192.168.3.142:2380 \ 
-initial-advertise-peer-urls http://192.168.3.142:2380 \ 
-listen-client-urls http://192.168.3.142:2379,http://127.0.0.1:23 
-advertise-client-urls http://192.168.3.142:2379 \ 
-initial-cluster etcdi=http://192.168.3.140:2380, etcd2=http://192 


-initial-cluster-state new 


动态 发 现 适用 于 无 法 事先 知道 Etcd 集 群 规模 和 每 个 节点 地 址 的 场 
景 ， 包 括 Etcd 动 态 发 现 和 DNS 动态 发 现 。 


Etcd 动 态 发 现 








Etcd 动 态 发 现 方 式 是 利用 一 个 已 有 的 Etcd 服 务 来 提供 服务 发 现 ， 从 
而 搭建 出 一 个 新 的 Etcd 集 群 。 


CoreOS 官 方 提供 了 免费 的 Etcd 发 现 服务 (discovery.etcd.io) ， 可 以 
用 来 帮助 初始 化 新 Etcd 集 群 。 通 过 浏览 器 或 者 命令 行 curl 访 问 地 址 
https://discovery.etcd.io， 可 以 得 到 一 个 新 的 集群 标识 URL， 比 如 创建 规 
模 数 目 为 3 的 集群 标识 URL: 


$ curl -w "\n" 'https://discovery.etcd.io/new?size=3' 


https://discovery.etcd.10/e1839e0d76aa687cb7c9bafcdf420F66 


和 输出 的 URL 是 搭建 Etcd 集 群 需要 使 用 到 的 ， 可 通过 环境 变量 设置 : 


$ export ETCD_CLUSTER_DISCOVERY_URL=https://discovery.etcd.io/ 


e1839e0d76aa687cb7c9bafcdf420f66 


如 果 无 法 使 用 discovery.etcd.io， 也 可 以 利用 已 有 的 Etcd 服务 ， 比 
如 Etcd 服 务 访问 地 址 是 http://myetcd.local， 我 们 同样 需要 创建 新 的 集群 
标识 URL， 首 先生 成 一 个 UUID: 


$ export ECTD CLUSTER UUID=$(cat /dev/urandom | base64 | tr -d "= 
$ echo $ECTD_CLUSTER_UUID 
Batno20LUGhFICsmuZiQgM7tG1Z84h2jLnmkLyf2 


然后 创建 集群 标识 Key， 其 中 设置 集群 规模 数目 为 3: 


$ curl -X PUT http://myetcd.1local/v2/keys/discovery/${ECTD_CLUSTE 


{"action":"set", "node": {"key":"/discovery/Batno20LUGhFICsmuZiQgM7 
通过 环境 变量 设置 集群 标识 URL: 
$ export ETCD_CLUSTER_DISCOVERY_URL=http://myetcd.local/v2/keys/d 


在 搭建 新 集群 的 时 候 ， 需 要 通过 -discovery 参 数 指定 我 们 创建 的 
URL， 分 别 在 3 个 节点 上 启动 Etcd: 





e Etcdl 


$ etcd -name etcd1 \ 

-data-dir /var/lib/etcd1 \ 

-listen-peer-urls http://192.168.3.140:2380 \ 
-initial-advertise-peer-urls http://192.168.3.140:2380 \ 
-listen-client-urls http://192.168.3.140:2379,http://127.0.0.1:23 
-discovery ${ETCD_CLUSTER_DISCOVERY_URL} \ 


-initial-cluster-state new 


e Etcd2 


$ etcd -name etcd2 \ 

-data-dir /var/lib/etcd2 \ 

-listen-peer-urls http://192.168.3.141:2380 \ 
-initial-advertise-peer-urls http://192.168.3.141:2380 \ 
-listen-client-urls http://192.168.3.141:2379,http://127.0.0.1:23 
-advertise-client-urls http://192.168.3.141:2379 \ 

-discovery ${ETCD_CLUSTER_DISCOVERY_URL} \ 


-initial-cluster-state new 


。 Etcd3 


$ etcd -name etcd3 \ 

-data-dir /var/lib/etcd3 \ 

-listen-peer-urls http://192.168.3.142:2380 \ 
-initial-advertise-peer-urls http://192.168.3.142:2380 \ 
-listen-client-urls http://192.168.3.142:2379,http://127.0.0.1:23 
-advertise-client-urls http://192.168.3.142:2379 \ 

-discovery ${ETCD_CLUSTER_DISCOVERY_URL} \ 


-initial-cluster-state new 


DNS 动态 发 现 





在 DNS 中 ， 一 个 域名 能 够 关联 香干 种 资源 记录 ， 除 了 我 们 比较 熟悉 
的 A 记录 (用 于 地 址 查询 ) 或 者 是 MX 记录 (用 于 邮件 服务 查询 )， 
DNS 还 定义 了 SRV 记 录 ， 可 以 用 于 服务 发 现 。 





Etcd 文 持 利 用 DNS SRV 记 录 实 现 互 相 发 现 ， 通 过 -discovery-srv 参 数 
设置 DNS SRV 域名， 比如 设置 成 example.com， 然 后 Etcd 会 依次 进行 查 


询 。 


_etcd- 


_etcd- 


server-ssl._tcp.example.com 


server. _tcp.example.com 


如 果 _etcd-server-ssl._tcp.example.com 解 析 成 功 ， 那 么 Etcd 束 会 使 用 
HTTPS/SSL 启 动 。 


对 于 我 们 要 搭建 的 集群 ， 首 先 要 创建 DNS SRV 记录 : 


$ dig +noall +answer SRV _etcd-server._tcp.example.com 


_etcd-server._tcp.example.com. 300 IN SRV © © 2380 etcd1.exampl 


_etcd-server._tcp.example.com. 300 IN SRV 0 0 2380 etcd2.exampl 


_etcd- 


$ dig 
etcdi1. 
etcd2. 


etcd3. 


server._tcp.example.com. 300 


+noall +answer etcd1.example 


example.com. 300 IN A 192. 
example.com. 300 IN A 192. 


example.com. 300 IN A 192. 





然后 分 别 在 3 个 节点 上 启动 Etcd。 


e Etcdl 


$ etcd -name etcd1 \ 


-data- 


dir /var/lib/etcdi1 和 


IN SRV 0 0 2380 etcd3.exampl 


.Com etcd2.example.com etcd3.ex 


168.3.140 
168.3.141 
168.3.142 


-listen-client-urls http://etcd1.example.com:2379 \ 


-advertise-client-urls http://etcd1.example.com:2379 \ 
-listen-peer-urls http://etcd1.example.com:2380 \ 
-initial-advertise-peer-urls http://etcd1.example.com:2380 \ 
-discovery-srv example.com \ 


-initial-cluster-state new 


e Etcd2 


$ etcd -name etcd2 \ 

-data-dir /var/lib/etcd2 \ 

-listen-client-urls http://etcd2.example.com:2379 \ 
-advertise-client-urls http://etcd2.example.com:2379 \ 
-listen-peer-urls http://etcd2.example.com:2380 \ 
-initial-advertise-peer-urls http://etcd2.example.com:2380 \ 
-discovery-srv example.com \ 


-initial-cluster-state new 


e Etcd3 


$ etcd -name etcd3 \ 

-data-dir /var/lib/etcd3 \ 

-listen-client-urls http://etcd3.example.com:2379 \ 
-advertise-client-urls http://etcd3.example.com:2379 \ 
-listen-peer-urls http://etcd3.example.com:2380 \ 
-initial-advertise-peer-urls http://etcd3.example.com:2380 \ 
-discovery-srv example.com \ 


-initial-cluster-state new 


14.3.2.2 ”集群 管理 


Etcd 集 群 搭建 完成 后 ， 可 以 查询 集群 成 员 : 


$ etcdctl member list 

f042ea167d8f2828: name=etcd1 peerURLSs=http://192.168.3.140:2380 c 
156ce626171618a6: name=etcd2 peerURLS=http://192.168.3.141:2380 c 
c99b1511c3ade2bb: name=etcd3 peerURLSs=http://192.168.3.142:2380 c 


以 及 集群 的 健康 状态 : 


$ etcdctl cluster-health 

member f042ea167d8f2828 is healthy: got healthy result from http: 
member 156ce626171618a6 is healthy: got healthy result from http: 
member c99b1511c3ade2bb is healthy: got healthy result from http: 


cluster is healthy 





增加 成 员 
添加 成 员 信息 : 


$ etcdctl member add etcd4 http://192.168.3.143:2380 
added member 4d906f7a642c3f23 to cluster 


ETCD_NAME="etcd4" 
ETCD_INITIAL_CLUSTER="etcdi=http://192.168.3.140:2380, etcd2=http 


ETCD_INITIAL_CLUSTER_STATE=existing 





添加 成 功 后 返回 的 信息 中 提示 设置 环境 变量 etcd_name、 


etcd_initial cluster#lletcd_ initial _ cluster_state， 这 将 可 以 在 启动 新 的 Etcd 


成 员 时 使 用 : 


$ etcd -name etcd4 \ 

-data-dir /var/lib/etcd4 \ 

-listen-client-urls http://192.168.3.143:2379 \ 
-advertise-client-urls http://192.168.3.143:2379 \ 
-listen-peer-urls http://192.168.3.143:2380 \ 
-initial-advertise-peer-urls http://192.168.3.143:2380 \ 
-initial-cluster $ETCD_INITIAL_CLUSTER \ 


-initial-cluster-state existing 


最 后 ， 可 以 查询 到 新 的 成 员 列 表 : 


$ etcdctl member list 

f042ea167d8f2828: name=etcd1 peerURLSs=http://192.168.3.140:2380 c 
156ce626171618a6: name=etcd2 peerURLS=http://192.168.3.141:2380 c 
c99b1511c3ade2bb: name=etcd3 peerURLS=http://192.168.3.142:2380 c 
Ad906f7a642c3f23: name=etcd4 peerURLSs=http://192.168.3.143:2380 c 


删除 成 员 


$ etcdctl member remove 4d906f7a642c3f23 


Removed member 4d906f7a642c3f23 from cluster 


$ etcdctl member list 
f042ea167d8f2828: name=etcd1 peerURLSs=http://192.168.3.140:2380 c 
156ce626171618a6: name=etcd2 peerURLSs=http://192.168.3.141:2380 c 


c99b1511c3ade2bb: name=etcd3 peerURLs=http://192.168.3.142:2380 c 
3 > O 
更 新 成 员 


$ etcdctl member update f042ea167d8f2828 http://etcd1.example.com 


Updated member with ID f042ea167d8f2828 in cluster 


$ etcdctl member list 

f042ea167d8f2828: name=etcd1 peerURLs=http://etcd1.example.com: 23 
156ce626171618a6: name=etcd2 peerURLS=http://192.168.3.141:2380 c 
c99b1511c3ade2bb: name=etcd3 peerURLS=http://192.168.3.142:2380 c 


迁移 成 员 


当 需 要 迁移 成 员 的 时 候 ， 实 际 上 等 效 于 删除 一 个 旧 成 员 ， 再 新 增 一 
个 新 成 员 ， 让 数据 自动 切换 ， 但 是 如 果 数 据 过 大 《大 于 50MB) ， 会 影 
啊 集 群 的 状态 。 更 安全 的 做 法 是 人 为 地 迁移 数据 ， 比 如 现在 需要 将 Etcd 
成 员 etcd3 从 机 器 1 (192.168.3.142) 迁移 机 器 2 (192.168.3.143) ， 步 又 
UF 


“。 ACTED LAS EPP IEEtcddERE, HOAR ANLA: 


$ kill ‘pgrep etcd 
$ tar -cvzf etcd3.data.tar.gz /var/lib/etcd3 


$ scp etcd3.data.tar.gz 192.168.3.143:~/ 


紧 接着 更 新 Etcd 成 员 : 


$ etcdctl member update c99b1511c3ade2bb http://192.168.3.143:238 


Updated member with ID c99b1511c3ade2bb in cluster 


然后 在 机 器 2 上 启动 Etcd: 


$ tar -xzvf etcd3.data.tar.gz -C /var/lib/etcd3 

$ etcd -name etcd3 \ 

-data-dir /var/lib/etcd3 \ 

-listen-peer-urls http://192.168.3.143:2380 \ 
-initial-advertise-peer-urls http://192.168.3.143:2380 \ 
-listen-client-urls http://192.168.3.143:2379,http://127.0.0.1:23 
-advertise-client-urls http://192.168.3.143:2379 


14.3.3 Etcd Proxy 模 式 


Etcd 可 以 设置 为 Proxy 模 式 ， 此 时 Etcd Proxy 并 不 是 直接 加 入 到 数据 
强 一 致 性 的 Etcd 和 集群 中 ， 所 以 Etcd ” Proxy 并 没有 增加 集群 的 可 靠 性 ， 当 
然 也 没有 降低 集群 的 写 入 性 能 。Etcd Proxy 只 是 作为 一 个 反 向 代理 把 客 
户 的 请 求 转发 给 可 用 的 Etcd 集 群 。 一 个 典型 的 应 用 场景 是 ， 在 客户 端 机 
器 本 地 运行 Etcd Proxy 来 对 接 真正 的 Etcd 服 务 端 集群 ， 对 客户 端 应 用 来 
说 可 以 直接 访问 本 地 的 Etcd Proxy (http:/127.0.0.1:2379) ， 而 不 用 感知 
Etcd 服 务 端 集群 的 变化 ， 因 为 Etcd Proxy 会 维护 同 Etcd 服 务 端 集群 的 同 
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启动 一 个 Etcd Proxy， 对 接 Etcd 集 群 : 


SRI 


$ etcd -proxy on \ 
-listen-client-urls http://127.0.0.1:4001 \ 
-initial-cluster etcd1i=http://192.168.3.140:2380, etcd2=http://192 


。Etcd 动 态 发 现 


$ etcd -proxy on \ 
-listen-client-urls http://127.0.0.1:4001 \ 
-discovery ${DISCOVERY_URL} 


。DNS 动 态 发 现 


$ etcd --proxy on \ 
-listen-client-urls http://127.0.0.1:4001 \ 


-discovery-srv example.com 


14.3.4 ”Etcd 的 安全 模式 


Etcd 中 的 通信 包括 Client-to-Server 和 Peer-to-Peer， 支 持 SSL/TLS 加 密 
和 Client Certificate Authentication 认 证 。 


Client-to-Server 通 信 
。 开 启 HTTPS 


开启 HTTPS， 需 要 CA 证 书 (server-ca.crt) 和 该 CA 签发 的 服务 端 密 


钥 对 (server.crt/ server.key) 。 运 行 Etcd: 


$ etcd -name etcd1 \ 


-cert-file=/path/to/server.crt -key-file=/path/to/server.key \ 
-advertise-client-urls=https://127.0.0.1:2379 \ 


-listen-client-urls=https://127.0.0.1:2379 


Etcd Client 通 过 HTTPS 访 问 Etcd Server 时 就 需要 提供 CA 证 书 


(server-ca.crt) : 


$ etcdctl --ca-file=/path/to/server-ca.crt -C https://127.0.0.1:2 
member ce2a822cea30bfca is healthy: got healthy result from https 


cluster is healthy 


。 开 局 Client Certificate Authentication 


在 开启 HTTPS 后 ， 可 以 开局 Client Certificate Authentication。 这 样 一 
来 ，Etcd Client 在 访问 Etcd Server 的 时 候 就 需要 提供 Client Certificate 进 行 
认证 ， 认 证 成 功 才 能 有 权限 访问 。 


同样 的 ， 需 要 CA 证 书 〈client-ca.crt) 和 该 CA 签发 的 客户 端 密 钥 对 
(client.crt/client.key) ， 签 发 客户 端 密 钥 对 和 签发 服务 端的 CA 可 以 一 
样 ， 这 实际 上 并 不 冲突 ， 因 为 一 个 CA 可 以 同时 签发 服务 端 密 钥 对 和 客 
户 端 密 钥 对 。 运 行 Etcd: 





$ etcd -name etcd1 -data-dir etcd1 \ 

-client-cert-auth -trusted-ca-file=/path/to/client-ca.crt \ 
-cert-file=/path/to/server.crt -key-file=/path/to/server.key \ 
-advertise-client-urls https://127.0.0.1:2379 \ 


-listen-client-urls https://127.0.0.1:2379 


h SeS 


如 Etcd Client 按 照 之 前 的 命令 访问 Etcd Server， 会 报错 : 


$ etcdctl --ca-file=/path/to/server-ca.crt -C https://127.0.0.1:2 
cluster may be unhealthy: failed to list members 
Error: client: etcd cluster is unavailable or misconfigured 


error #0: remote error: bad certificate 


为 Etcd Client 需 要 提供 Client Certificate， 才 能 认证 成 功 : 


$ etcdctl --ca-file=/path/to/server-ca.crt \ 
--key-file=/path/to/client.key --cert-file=/path/to/client.crt \ 
-C https://127.0.0.1:2379 \ 

cluster-health 

member ce2a822cea30bfca is healthy: got healthy result from https 


cluster is healthy 
Peer-to-Peer {5 
¢ Ft AHTTPS Client Certificate Authentication 


类 似 的 ，Etcd ” Peer 之 间 的 通信 开启 HTTPS 和 Client Certificate 
Authentication， 需 要 准备 CA 证 书 〈ca.crt) ， 为 每 个 Peer 签发 一 个 密 针 


Xf Cserverl.key#llserverl.crt, server2.key#llserver2.crt) 。 
e Etcd1 


$ etcd -name etcd1 \ 

-peer-client-cert-auth -peer-trusted-ca-file=/path/to/ca.crt \ 
-peer-cert-file=/path/to/serveri.crt -peer-key-file=/path/to/serv 
-listen-peer-urls=https://192.168.3.140:2380 \ 


-initial-advertise-peer-urls=https://192.168.3.140:2380 \ 


-initial-cluster etcdi=https://192.168.3.140:2380, etcd2=https://1 


-initial-cluster-state new 


e Etcd2 


$ etcd -name etcd2 \ 

-peer-client-cert-auth -peer-trusted-ca-file=/path/to/ca.crt \ 
-peer-cert-file=/path/to/server2.crt -peer-key-file=/path/to/serv 
-listen-peer-urls=https://192.168.3.141:2380 \ 
-initial-advertise-peer-urls=https://192.168.3.141:2380 \ 
-initial-cluster etcd1i=http://192.168.3.140:2380, etcd2=http://192 
-initial-cluster etcdi=https://192.168.3.140:2380, etcd2=https://1 


-initial-cluster-state new 


P15% 
Mesos 


Mesos 是 一 个 成 熟 的 架构 ， 一 方面 提供 了 同 Kubernetes 类 似 的 容器 集 
群 管理 方案 ， 另 一 方面 ，Mesos 正 积极 同 Kubernetes 进 行 整合 ，Mesos 和 
Kubernetes 亦 敌 亦 友 。 本 章 将 介绍 Mesos， 以 及 Marathon 和 K8SM， 最 后 
说 明 如 何 使 用 这 3 个 项 目 。 





15.1 Mesos 介 绍 





Apache Mesos 是 由 加 州 大 学 伯克利 分 校 的 AMPLab 上 站 先 开 发 的 一 于 
开源 集群 管理 软件 ， 支 持 Hadoop、Elasticsearch、Spark、Storm 和 Kafka 
等 架构 。 其 开源 性 越 来 越 受到 一 些 大 型 云 计算 公 司 的 青睐 ，Twitter 和 
Airbnb 公 司 已 经 将 其 大 规模 应 用 在 其 数据 中 心中 了 。 现 在 ， 一 家 初创 公 
司 Mesosphere 将 Mesos 定 位 为 数据 中 心 操 作 系 统 (Data Center Operating 
System, DCOS) ， 使 之 步 入 主流 。 


Mesos 在 多 种 不 同类 型 的 工作 之 间 共 孚 机 器 《或 者 节点 ) 的 可 用 资 
源 ， 如 图 15-1 所 示 。Mesos 可 以 看 作 古 数据 中 心 的 内 核 ， 提 供 所 有 节 扣 
资源 的 统一 视图 ， 所 起 的 作用 类 似 于 操作 系统 内 核 在 单 台 机 顺 上 的 作 
用 ， 可 以 无 颖 地 访问 多 节点 资源 。 





Topobgy 1 
Topobgy 2 





Storm i 
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图 15-1 Mesos 的 层次 
15.2 Mesoshy 2244 


Mesos 的 架构 如 图 15-2 所 示 ， 主 要 的 角色 有 Mesos 


Master. Mesos 
Slave, Framework#iExecutor. 


Scheduler Scheduler quorum 


Hadoop MPI 
Executor Executor 


图 15-2 Mesos% 45 





e Mesos ”Master 是 整个 系统 的 核心 ， 负 贡 管 理 接 入 Mesos 的 各 个 
Framework#llMesos Slave， 并 将 Mesos Slave 上 的 资源 按照 某 种 策略 分 配 


给 Framework。 


e Mesos Slave 负 责 接 收 并 执行 来 自 Mesos Master 的 命令 、 管 理 节点 
上 的 任务 ， 并 为 各 个 任务 分 配 资源 。Mesos Slave 将 自己 的 资源 量 发 送 给 
Mesos Master， 由 Mesos Master 决 定 将 资源 分 配给 哪个 Framework， 并 且 
当 任 务 运行 时 ，Mesos ”Slave 会 将 任务 放 到 包含 固定 资源 的 Linux 容 器 中 
运行 ， 以 达到 资源 隔离 的 效果 。 


。 Framework 是 指 外 部 的 计算 框架 ， 如 Hadoop、Elasticsearch、 
Spark、Storm 和 Kafka 等 ， 这 些 计算 框架 可 通过 注册 的 方式 接 入 Mesos， 
以 便 Mesos 进 行 统一 管理 和 资源 分 配 。Mesos 要 求 可 接 入 的 Framework 必 
须 有 一 个 调度 器 模块 ， 该 调度 器 负 贡 Framework 内 部 的 任务 调度 。 当 一 
个 Framework 想 要 接 入 Mesos 时 ， 需 要 修改 自己 的 调度 器 ， 以 便 向 Mesos 


注册 ， 并 获取 Mesos 分 配给 自己 的 资源 ， 这 样 再 由 调度 器 将 这 些 资源 分 
配给 Framework 中 的 任务 。 也 就 是 说 ， 整 个 Mesos 系 统 采 用 了 双 层 调度 
框架 : 第 一 层 ， 由 Mesos 将 资源 分 配给 Framework; 第 二 层 ，Framework 


的 调度 器 将 资源 分 配给 上 自己 内 部 的 任务 。 








Executor 主 要 用 于 启动 Frameworkk 内 部 的 任务 。 由 于 不 同 的 
Framework 局 动 任务 的 接口 或 者 方式 不 同 ， 当 一 个 新 的 Framework 要 接 
入 Mesos 时 ， 需 要 编写 一 个 Executor， 告 诉 Mesos 如 何 启动 该 Framework 


中 的 任务 。 





15.3 ”Marathon 和 K8SM 介 绍 


15.3.1 Marathon 


Marathon 是 一 个 Mesos ”Framework， 正 如 其 名 字 “ 马 拉 松 ”， 用 来 支 
持 运 行 长 期 服务 ， 比 如 Web 应 用 等 。Marathon 能 够 保证 这 些 服务 的 高 可 
用 性 ， 也 就 是 说 ， 当 某 人 台 机 器 发 生 故 障 时 ， 能 够 在 其 他 机 器 上 启动 服 
务 。Marathon 是 集群 的 分 布 式 Init.d， 能 够 原样 运行 任何 Linux 二 进 制 发 
布 版 本 ， 如 Tomcat、Play 等 ， 它 也 是 一 种 私有 的 PaaSs， 提 供 REST API 服 
务 ， 实 现 服 务 的 发 现 ， 有 授权 和 SSL、 配 置 约 束 ， 通 过 HAProxy 实 现 服 
务 发 现 和 负载 平衡 。 更 重要 的 是 ，Marathon 已 经 集成 了 Docker， 
Mesos+Marathon 是 比较 成 熟 的 容器 集群 管理 解决 方案 ， 已 经 在 众多 知名 
企业 的 生产 环境 中 使 用 。 图 15-3 所 示 为 Marathon 的 结构 图 。 
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图 15-3 Marathon2é #4 


15.3.2 K8SM 


K8SM (Kubernetes-Mesos) 是 一 个 将 Kubernetes 整 合 到 Mesos 中 的 
项 目 ， 作 为 Mesos Framework， 能 够 将 Kubernetes 处 理 并 运行 在 Mesos 之 
上 ， 且 可 以 同 任意 数量 的 其 他 Mesos 框 架 〈 包 括 Marathon、Spark、 
Kafka 以 及 Jenkins 等 ) 实现 同 地 协作 ， 从 而 共 至 来 自 同一 套 集群 中 的 各 
类 资源 。 








Kubernetes 是 一 个 轻 量 级 的 容 右 管理 平台 ， 可 深度 和 灵活 地 进行 容 
量 编排 ， 而 Mesos 是 分 布 式 系统 内 核 ， 它 可 以 将 不 同 的 机 器 整合 在 一 个 
逻辑 计算 机 中 ， 有 着 非常 优秀 的 资源 调度 集 略 ， 可 以 认为 Mesos 和 
Kubernetes 的 愿景 差不多 ， 而 K8SM 则 整合 了 两 者 ，K8SM 的 架构 如 图 
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图 15-4 K8SM 架 构 


15.4 Mesos 实 践 


15.4.1 运行 Mesos 


1. 运行 Zookeeper。 


$ docker run -d \ 
--name zookeeper --net host \ 


mesoscloud/zookeeper :3.4.6 


2. i847 Mesos Master. 


$ docker run -d \ 

-e MESOS_HOSTNAME=mesos-master \ 

-e MESOS _IP=<mesos-master-ip> \ 

-e MESOS_QUORUM=1 \ 

-e MESOS_ZK=zk://<zookeeper-ip>:2181/mesos \ 
--name mesos-master --net host \ 


mesoscloud/mesos-master:0.24.1 


3. i847 Mesos Slave. 


$ docker run -d \ 

-e MESOS HOSTNAME=mesos-slave \ 

-e MESOS _IP=<mesos-slave-ip> \ 

-e MESOS MASTER=zk://<zookeeper-ip>:2181/mesos \ 
-v /sys/fs/cgroup:/sys/fs/cgroup \ 

-v /var/run/docker.sock:/var/run/docker.sock \ 
--name mesos-slave --net host --privileged \ 


mesoscloud/mesos-slave:0.24.1 


提示 


Mesos Slave 节 点 上 需要 预先 安装 好 Docker(V1.9.1)。 





4. 待 Mesos 运 行 正 常 后 ， 可 以 通过 默认 5050 站 口 访问 Mesos Web 界 
面 ， 如 图 15-5 所 示 。 


i | 


Cluster: (Unnamed Active Tasks 
Server: 10.0.22.8:5050 


Version: 0.24 10 Name State Started ¥ Host 


No active tasks 


Completed Tasks 
Slaves ID Name State Started ¥ Stopped Kost 


Activated No completed tasks 











图 15-5 Mesos Web 界 面 





同时 可 以 查询 到 Mesos Slave， 如 图 15-6 所 示 。 


vea | 


Slaves 
ID Host CPUs Mem Disk Registered Re-Registered 











图 15-6 查询 Mesos Slave 


15.4.2 ”运行 MIarathon 


1. 运行 Marathon 。 


$ docker run -d \ 

-e MARATHON_HOSTNAME=marathon \ 

-e MARATHON_HTTP_ADDRESS=<marathon-ip> \ 

-e MARATHON_MASTER=zk://<zookeeper -ip>:2181/mesos \ 
-e MARATHON_ZK=zk://<zookeeper -ip>:2181/marathon \ 
--name marathon --net host \ 


mesoscloud/marathon:0.11.0 





2. Marathon 运 行 成 功 后 ， 在 Mesos 界 面 上 可 以 查询 到 Marathon 注 册 
童 轧 ， 如 网 15-7 所 示 。 同 时 可 以 通过 8080 端 口 访问 Marathon Web 界 面 ， 
如 图 15-8 所 示 。 


3. 通过 调用 Marathon REST API 创 建 应 用 。 


$ curl -v \ 

-X POST -H "Content-Type: application/json" \ 
--data "@app.json" \ 
http://<marathon-ip>:8080/v2/apps 


其 中 app.json 是 应 用 的 定义 文件 ， 内 容 如 下 : 


"id": "web-app", 

"cmd": "python3 -m http.server 8080", 
"cpus": 0.5, 

"mem": 32.0, 

"instances": 1, 


"container": { 


"type": "DOCKER", 


"docker": { 


"image": "python:3", 


"network": "BRIDGE", 


"portMappings": [ 


{ "containerPort": 8080, "hostPort": © } 
] 
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图 15-7 查询 Marathon 注 册 信 息 





图 15-8 Marathon Web 界 面 





在 应 用 定义 文件 中 首先 指定 了 应 用 的 ID、 资 源 规格 和 运行 实例 数 ， 
在 container 属 性 中 配置 了 Docker 容 器 的 运行 参数 。 


应 用 创建 成 功 后 ，Mesos ”Slave 将 会 运行 起 配置 的 Docker 容 器 。 田 
外 ， 在 Marathon Web 界 面 可 以 查询 到 应 用 详情 ， 如 图 15-9 所 示 。 





/web-app 





图 15-9 ”查询 应 用 详情 


15.4.3 ig{7K8SM 


1. 构建 K8SM。 


$ git clone https://github.com/kubernetes/kubernetes 
$ export KUBERNETES_CONTRIB=mesos 


$ make 





编译 成 功 后 ， 可 执行 程序 在 _output/local/go/bin 目 录 下 可 以 设置 到 系 
统 环境 变量 中 : 


$ export PATH="$(pwd)/_output/local/go/bin: $PATH" 
2. 局 动 K8SM。 


设置 Mesos Master 的 地 址 : 


$ export MESOS MASTER=<mesos-master -ip>:5050 


然后 配置 文件 mesos-cloud.conf: 


$ cat <<EOF >mesos-cloud.conf 
[mesos-cloud | 
mesos-master = ${MESOS_MASTER} 


EOF 
设置 环境 变量 : 


$ export KUBERNETES MASTER_IP=$(hostname -i) 


$ export KUBERNETES MASTER=http://${KUBERNETES MASTER_IP}:8888 


首先 运行 Etcd: 


$ docker run -d \ 

-p 4001:4001 -p 7001:7001 \ 

--hostname $(uname -n) --name etcd \ 

quay .io/coreos/etcd:v2.0.12 \ 
--listen-client-urls http://0.0.0.0:4001 \ 


--advertise-client-urls http://0.0.0.0:4001 


然后 运行 K8SM 组 件 : 


$ km apiserver \ 

--address=${KUBERNETES MASTER_IP} \ 
--etcd-servers=http://127.0.0.1:4001 \ 
--service-cluster-ip-range=10.10.10.0/24 \ 
--port=8888 \ 

--cloud-provider=mesos \ 
--cloud-config=mesos-cloud.conf \ 
--secure-port=0 \ 


--v=1 >apiserver.log 2>&1 & 


$ km controller-manager \ 
--master=http://${KUBERNETES MASTER_IP}:8888 \ 
--cloud-provider=mesos \ 
--cloud-config=./mesos-cloud.conf \ 


--v=1 >controller.log 2>&1 & 


$ km scheduler \ 


--address=${KUBERNETES_MASTER_IP} \ 

- -mesos-master=${MESOS_MASTER} \ 
--etcd-servers=http://127.0.0.1:4001 \ 
--mesos-user=root \ 
--api-servers=${KUBERNETES_MASTER_IP}:8888 \ 
--cluster-dns=10.10.10.10 \ 
--cluster-domain=cluster.local \ 


--v=2 >scheduler.log 2>&1 & 
3.K8SM 运 行 成 功 后 可 以 进行 查询 。 


$ kubectl -s http://${KUBERNETES MASTER_IP}:8888 get services 


NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELEC 
k8sm-scheduler 10.10.10.132 <none> 10251/TCP <none 
kubernetes 10.10.10.1 <none> 443/TCP <non 





同时 在 Mesos _ Web 界面 上 可 以 查询 到 K8SM 注 册 信 息 ， 如 图 15-10 所 
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图 15-10 查询 K8SM 注 册 信息 


4. 使 用 K8SM 运 行 Pod。 


$ kubectl -s http://${KUBERNETES_MASTER_IP}:8888 run nginx --imag 


replicationcontroller "nginx" created 


当 有 Pod 创 建 后 ，K8SM Scheduler 癌 Mesos 申 请 资源 ， 然 后 K8SM 
Scheduler 根 据 Mesos 提 供 的 资源 绑 定 Pod 到 指定 的 Mesos Slave。 这 时 
候 ，K8SM 目 动 会 在 Mesos Slave 上 运行 K8SM ”Executor， 其 中 包括 
Kubelet 和 Kube Proxy 组 件 。 相 应 的 ， 该 Mesos Slave 也 会 被 作为 
Kubernetes Node: 


$ kubectl -s http://${KUBERNETES MASTER_IP}:8888 get node 
NAME LABELS STATU 


mesos-Slave kubernetes.io0/hostname=mesos-slave Ready 22s 


最 后 在 Mesos Slave 上 ，K8SM 将 会 运行 起 Pod: 


$ kubectl -s http://${KUBERNETES MASTER_IP}:8888 get pod --select 
NAME READY STATUS RESTARTS AGE 
nginx-1dk7d 1/1 Runing 0 1m 
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第 1 版 推荐 序 


经 过 作者 们 多 年 的 实践 经 验 积 囚 及 近 一 年 的 精心 准备 ， 本 书 终 于 与 
我 们 大 家 见面 了 。 我 有 至 作 为 首 批 读者 ， 提 前 见证 和 学 习 了 在 云 时 代 引 
领 业界 技术 方向 的 Kubernetes 和 Docker 的 最 新 动态 。 


从 内 容 上 讲 ， 本 书 从 一 个 开发 者 的 角度 去 理解 、 分 析 和 解决 问题 : 
从 基础 入 门 到 架构 原理 ， 从 运行 机 制 到 开发 源码 ， 再 从 系统 运 维 到 应 用 
实践 ， 讲 解 全面 。 本 书 图 文 并 戊 ， 斥 容 丰富 ， 由 浅 入 深 ， 对 基本 原理 曾 
述 清 晰 ， 对 程序 源码 分 析 透 彻 ， 对 实践 经 验 体会 深刻 。 





我 认为 本 书 值 得 推荐 的 原因 有 以 下 几 点 。 


首先 ， 作 者 的 所 有 观点 和 经 验 ， 均 是 在 多 年 建设 、 维 护 大 型 应 用 系 
统 的 过 程 中 积累 形成 的 。 例 如 ， 读 者 通过 学 习 书 中 的 Kubernetes 运 维 指 
南 和 高 级 应 用 实践 案例 章节 的 内 容 ， 不 仅 可 以 直接 提高 开发 技能 ， 还 可 
以 解决 在 实践 过 程 中 经 常 遇 到 的 各 种 关键 问题 。 书 中 的 这 些 内 容 具 有 很 
高 的 借鉴 和 推广 意义 。 














其 次 ， 通 过 大 量 的 实例 操作 和 详尽 的 源码 解析 ， 本 书 可 以 帮助 读者 
进一步 深刻 理解 Kubernetes 的 各 种 概念 。 例 如 书 中 “Java 访 问 Kubernetes 
AP 的 几 种 方法 ， 读 者 参照 其 中 的 案例 ， 只 要 稍 做 修改 ， 再 结合 实际 的 
应 用 需求 ， 就 可 以 用 于 正在 开发 的 项 目 中 ， 达 到 事半功倍 的 效果 ， 有 利 





于 有 一 定 Java 基 础 的 专业 人 士 快 速 学 习 Kubernetes 的 各 种 细节 和 实践 操 
人 





再 次 ， 为 了 让 初学 者 快速 入 门 ， 本 书 配备 了 即时 在 线 交 流 工具 和 专 
业 后 人 台 技 术 文 持 团 队 。 如 果 你 在 开 有 发 和 应 用 的 过 程 中 遇 到 各 类 相关 问 
题 ， 均 可 直接 联系 该 团队 的 开发 文 持 专家 。 


最 后 ， 我 们 可 以 看 到 ， 容 器 化 技术 已 经 成 为 计算 模型 演化 的 一 个 开 
端 ，Kubernetes 作 为 谷歌 开源 的 Docker 容 器 集群 管理 技术 ， 在 这 场 新 的 
技术 革命 中 扮演 着 重要 的 角色 。Kubernetes 正 在 被 众多 知名 企业 所 采 
用 ， 例 如 RedHat、VMware、CoreOS 及 腾讯 等 ， 因 此 ，Kubernetes 站 在 
了 容器 新 技术 变革 的 当 测 之 题 ， 将 具有 不 可 预 估 的 发 展 前 景 和 商业 价 
值 。 





如 果 你 是 初级 程序 员 ， 那 么 你 有 必要 好 好 学 习 本 书 ; 如 果 你 正在 全 
领域 进行 高 级 进 阶 修炼 ， 那 你 也 有 必要 陪读 本 书 。 无 论 是 架构 师 、 开 发 
者 、 运 维 人 员 ， 还 是 对 容器 技术 比较 好 奇 的 读者 ， 本 书 都 是 一 本 不 可 多 
得 的 带 你 从 入 门 回 高 级 进 阶 的 精品 蔬 ， 值 得 大 家 选择 ! 

初 瑞 


中 国 移动 业务 文 撑 中 心 高 级 经 理 


A 








我 不 知道 你 是 如 何 获得 这 本 书 的 ， 可 能 是 在 百度 头条 、 网 络 广告 、 
朋友 闪 中 听 说 本 书后 购买 的 ， 也 可 能 是 茶 一 天 和 逛 书店 时 ， 这 本 书 恰 好 神 
奇 地 翻 落 书 架 ， 出 现在 你 面前 ， 让 你 想起 一 千 多 年 前 那个 意外 得 到 《 太 
ARRI WATE, Wee RR SHLAA, Toe Ri 
走 。 不 管 怎样 ， 我 相信 多 年 以 后 ， 这 本 书 仍然 值得 你 回忆 。 

















Kubernetes 这 个 名 字 起 源 于 古 希 腊 ， 是 和 能手 的 意思 ， 所 以 它 的 Logo 
既 像 一 张 渔网 ， 又 像 一 个 罗盘 。 谷 歌 末 用 这 个 名 字 的 一 层 深意 就 是 既 
然 Docker 把 自己 定位 为 驮 着 集装箱 在 大 海上 自在 邀 游 的 稣 色 ， 那 么 谷歌 
就 要 以 Kubernetes 掌 舵 大 航海 时 代 的 话语 权 , “捕获 ”和 “指引 ”这 条 鲸鱼 
按照 < 主人” 设 定 的 路 线 了 巡游 ， 确 保 谷 歌 倾 力 打 造 的 新 一 代 容 器 世界 的 宏 
伟 蓝 图 顺利 实现 。 











里 然 Kubernetes 自 诞生 至 今 才 1 年 多 ， 其 第 一 个 正式 版 本 Kubernetes 
1.0 于 2015 年 7 月 才 发 布 ， 完 全 是 个 新 生 事 物 ， 但 其 影响 力 巨 大 ， 已 经 吸 
引 了 包括 IBM、 惠 普 、 微 软 、 红 帽 、Intel、VMware、CoreOS、 
Docker、Mesosphere、Mirantis 等 在 内 的 众多 业界 巨头 纷纷 加 入 。 红 帽 这 
个 软件 虚拟 化 领域 的 领导 者 之 一 ， 在 容器 技术 方面 已 经 完全 “跟从 ”谷歌 
了 ， 不 仅 把 自家 的 第 三 代 OpenShift 产 品 的 架构 底层 换 成 了 
Docker+Kubernetes， 还 直接 在 其 新 一 代 容 器 操作 系统 Atomic 内 原生 集成 





了 Kubernetes 。 


Kubernetes 是 第 一 个 将 “一 切 以 服务 (Service) 为 中 心 ， 一切 围 绕 服 
务 运转 ”作为 指导 思想 的 创新 型 产品 ， 它 的 功能 和 架构 设计 自始至终 都 
遵循 了 这 一 指导 思想 ， 构 建 在 Kubernetes 上 的 系统 不 仅 可 以 独立 运行 在 
物理 机 、 虚 拟 机 集群 或 者 企业 私有 云 上 ， 也 可 以 被 托管 在 公有 云 中 。 
Kubernetes 方 案 的 男 一 个 亮点 是 自动 化 ， 在 Kubernetes 的 解决 方案 中 ， 一 
个 服务 可 以 自我 扩展 、 自 我 诊断 ， 并 且 容 易 升 级 ， 在 收 到 服务 扩容 的 请 
求 后 ，Kubernetes 会 触发 调度 流程 ， 最 终 在 选 定 的 目标 节点 上 局 动 相应 
数量 的 服务 实例 副本 ， 这 些 副 本 在 启动 成 功 后 会 自动 加 入 负载 均衡 器 中 
并 生效 ， 整 个 过 程 无 顷 额 外 的 人 工 操作 。 另 外 ，Kubernetes 会 定时 巡 碍 
每 个 服务 的 所 有 实例 的 可 用 性 ， 确 保 服务 实例 的 数量 始终 保持 为 预期 的 
数量 ， 当 它 发 现 某 个 实例 不 可 用 时 ， 会 自动 重启 该 实例 或 者 在 其 他 市 点 
重新 调度 、 运 行 一 个 新 实例 ， 这 样 ， 一 个 复杂 的 过 程 无 顷 人 工 干 预 即 可 
全 部 自动 化 完成 。 试 想 一 下 ， 如 采 一 个 包括 几 十 个 节点 且 运 行 着 几 万 个 
容器 的 复杂 系统 ， 其 负载 均衡 、 故 障 检测 和 故障 修复 等 都 需要 人 工 介 入 
进行 处 理 ， 那 将 是 多 么 难以 想象 。 
































通常 我 们 会 把 Kubernetes 看 作 Docker 的 上 层 架 构 ， 就 好 像 Java 与 
J2EE 的 关系 一 样 : J2EE 是 以 Java 为 基础 的 企业 级 软件 架构 ， 而 
Kubernetes 则 以 Docker 为 基础 打造 了 一 个 云 计 算 时 代 的 全 新 分 布 式 系统 
架构 。 但 Kubernetes 与 Docker 之 间 还 存在 着 更 为 复杂 的 关系 ， 从 表面 上 
看 ， 似 乎 Kubernetes 离 不 开 Docker， 但 实际 上 在 Kubernetes 的 架构 里 ， 
Docker 只 是 其 目前 文 持 的 两 种 底层 容器 技术 之 一 ， 另 一 个 容器 技术 则 是 
Rocket， 后 者 来 源 于 CoreOS 这 个 Docker 昔 日 的 “恋人 ”所 推出 的 竞争 产 
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史 原 因 的 。 快 速 友 展 的 Docker 打 败 了 谷歌 曾经 名 噪 一 时 的 开源 容器 技术 
lmctfy， 并 迅速 风靡 世界 。 但 是 ， 作 为 一 个 已 经 对 全 球 IT 公司 产生 重要 
影响 的 技术 ，Docker 背 后 的 容器 标准 的 制定 注定 不 可 能 被 任何 一 个 公司 
私有 控制 ， 于 是 就 有 了 后 来 引发 危机 的 CoreOS 与 Docker 分 手 事件 ， 其 导 
火 过 是 CoreOS 撤 开 了 Docker， 推 出 了 与 Docker 相 对 抗 的 开源 容器 项 目 
Rocket， 并 动员 一 些 知 名 I 公司 成 立 委 员 会 来 试图 主导 容器 技术 的 
标准 化 ， 该 分 手 事件 愈演愈烈 ， 最 终 导 致 CoreOS“ 傍 上 ”谷歌 一 起 宣 
布 “ 叛 逃 ?Docker 阵 营 ， 共 同 发 起 了 基于 CoreOS+Rocket+Kubernetes 的 新 
项 目 Tectonic。 这 让 当时 的 Docker 阵 营 和 Docker 粉 丝 们 无 比 担心 Docker 
的 命运 ， 不 管 最 终 鹿死谁手 ， 容 器 技术 分 裂 态势 的 加 剧 对 所 有 牵涉 其 中 
的 人 来 说 都 没有 好 处 ， 于 是 Linux 基 金 会 出 面 调 和 和 矛盾 ， 双 方 都 退让 一 
步 ， 最 终 的 结果 是 Linux 基 金 会 于 2015 年 6 月 宣布 成 立 开 放 容 器 技术 项 目 
(Open Container Project) ， 人 谷歌 、CoreOS 及 Docker 都 加 入 了 OCP 项 
目 。 但 通过 但 看 OCP 项 目的 成 员 名 单 ， 你 会 发 现 Docker 在 这 个 名 单 中 内 
能 算 一 个 小 角色 了 。OCP 的 成 立 最 终结 束 了 这 场 让 无 数 人 揪心 的 “ 战 
争 ”，Docker 公 司 被 迫 放 弃 了 自己 的 独家 控制 权 。 作 为 回报 ，Docker 的 
容器 格式 被 0CP 采 纳 为 新 标准 的 基础 ， 并 且 由 Docker 负 责 起 草 OCP 草 案 
规范 的 初稿 文档 ， 当 然 这 个 “标准 起 草 者 ”的 角色 也 不 是 那么 容易 担当 
的 ，Docker 要 提交 自己 的 容器 执行 引擎 的 源码 作为 OCP 项 目的 启动 资 

















事 到 如 今 ， 我 们 再 来 回顾 当初 CoreOSs 与 谷歌 的 叛逃 事件 ， 从 表面 
上 看 ， 谷 歌 貌 似 是 被 诱拐 “出 柜 ” 的 ， 但 局 里 人 都 明白 ， 人 谷歌 才 是 这 一 系 
列 事件 背后 的 主谋 ， 其 不 仅 为 当年 失败 的 lmctfy 报 了 一 第 之 仇 ， 还 重新 
掌控 了 容器 技术 的 未 来 。 容 器 标准 之 战 大 捷 之 后 ， 谷 歌 进 一 步 扩大 了 联 
盟 并 提高 了 自身 影响 力 。2015 年 7 月 ， 谷 歌 正式 宣布 加 入 OpenStack 阵 
营 ， 其 目标 是 确保 Linux 容 器 及 关联 的 容器 管理 技术 Kubernetes 能 够 被 

















OpenStack 生 态 圈 所 容纳 ， 并 且 成 为 OpenStack 平 台 上 与 KVM 虚 机 一 样 的 
一 等 公民 。 人 和 谷歌 加 入 OpenStack 意 味 痢 对 数据 中 心 控 制 平 面 的 争夺 已 经 
结束 ， 以 容器 为 代表 的 应 用 形态 与 以 虚拟 化 为 代表 的 系统 形态 将 会 完 
融合 于 OpenStack 之 上 ， 并 与 软件 定义 网 络 和 软件 定义 存储 一 起 统治 下 
一 代数 据 中 心 。 














谷歌 凭借 着 几 十 年 大 规模 容器 使 用 的 丰富 经 验 ， 步 步 为 营 ， 先 是 各 
出 Kubernetes 这 个 神器 ， 然 后 又 掌控 了 容器 技术 的 制定 标准 ， 最 后 义 入 
驻 OpenStack 阵 营 全 力 将 Kubernetes 扶 上 位 ， 谷 歌 这 个 IT 界 的 领导 者 和 创 
新 者 再 次 王者 归来 。 我 们 都 明日 ， 在 全 世界 里 只 有 那些 被 大 公司 掌控 和 
推广 的 ， 同 时 被 业界 众多 巨头 都 认可 和 文 持 的 新 技术 才能 生存 和 壮大 下 
去 。Kubernetes 就 是 当今 IT 界 里 符合 要 求 且 为 数 不 多 的 热门 技术 之 一 ， 
它 的 影响 力 可 能 长 达 十 年 ， 所 以 ， 我 们 每 个 IT 人 都 有 理由 重视 这 门 新 技 
术 。 


谁 能 比 别 人 领先 一 步 掌握 新 技术 ， 谁 束 在 竞争 中 赢得 了 先 机 。 惠 普 
中 国电 信和 解决 方案 领域 的 资深 专家 团 一 起 分 工 协 作 ， 并 行 研究 ， 瞩 寝 坊 
食 地 合力 撰写 ， 在 短 短 的 5 个 月 内 完成 了 这 部 厚 达 500 多 页 的 Kubernetes 
权威 指南 。 经 过 一 年 的 高 速 发 展 ，Kubernetes 先 后 发 布 了 1.1、1.2 和 1.3 
版 本 ， 每 个 版 本 都 市 来 了 大 量 的 新 特性 ， 能 够 处 理 的 应 用 场景 也 越 来 越 
丰富 。 本 书 遵循 从 入 门 到 精通 的 学 习 路 线 ， 全 书 共 分 为 六 大 音节， 涵盖 
了 入 门 、 实 践 指 南 、 架 构 原 理 、 开 发 指南 、 高 级 案例 、 运 维 指南 和 源码 
分 析 等 内 容 ， 内 容 详实 、 图 文 并 成 ， 几 乎 吉 括 了 Kubernetes 1.3 版 本 的 方 
方面 面 ， 无 论 是 对 于 软件 工程 师 、 测 试 工 程 师 、 运 维 工 程 师 、 软 件 架构 
师 、 技 术 经 理 ， 还 是 对 于 资深 IT 人 士 来 说 ， 本 书 都 极 具 参 考 价值 。 
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1.1 Kubernetes 是 什么 


Kubernetes 是 什么 ? 





首先 ， 它 是 一 个 全 新 的 基于 容器 技术 的 分 布 式 架构 领先 方案 。 这 个 
方案 虽然 还 很 新 ， 但 它 是 谷歌 十 几 年 以 来 大 规模 应 用 容器 技术 的 经 验 积 
累 和 升华 的 一 个 重要 成 果 。 确 切 地 说 ，Kubernetes 是 谷歌 严格 保密 十 几 
年 的 秘密 武器 一 一 Borg 的 一 个 开源 版 本 。Borg 是 谷歌 的 一 个 久负盛名 的 
内 部 使 用 的 大 规模 集群 管理 系统 ， 它 基于 容器 技术 ， 目 的 是 实现 资源 管 
理 的 自动 化 ， 以 及 跨 多 个 数据 中 心 的 资源 利用 率 的 最 大 化 。 十 几 年 来 ， 
谷歌 一 直通 过 Borg 系 统管 理 着 数量 庞大 的 应 用 程序 集群 。 由 于 谷歌 员工 
都 签署 了 保密 协议 ， 即 便 离职 也 不 能 泄露 Borg 的 内 部 设计 ， 所 以 外 界 一 
直 无 法 了 解 关 于 它 的 更 多 信息 。 直 到 2015 年 4 月 ， 传 闻 许 久 的 Borg 论 文 
伴随 Kubernetes 的 高 调 宣传 被 谷歌 首次 公开 ， 大 家 才 得 以 了 解 它 的 更 多 
内 幕 。 正 是 由 于 站 在 Borg 这 个 前 奉 的 肩膀 上 ， 吸 取 了 Borg 过 去 十 年 间 的 
经 验 与 教训 ， 所 以 Kubernetes 一 经 开源 就 一 鸣 怀 人 ， 并 迅速 称霸 了 容器 
技术 领域 。 








其 次 ， 如 果 我 们 的 系统 设计 遵循 了 Kubernetes 的 设计 思想 ， 那 么 传 
统 系统 架构 中 那些 和 业务 没有 多 大 关系 的 底层 代码 或 功能 模块 ， 都 可 以 


立刻 从 我 们 的 视线 中 消失 ， 我 们 不 必 再 费心 于 负载 均衡 器 的 选 型 和 部 署 
实施 问题 ， 不 必 再 考虑 引入 或 自己 开发 一 个 复杂 的 服务 治理 框架 ， 不 必 
再 头疼 于 服务 监控 和 故障 处 理 模块 的 开发 。 总 之 ， 使 用 Kubernetes 提 供 
的 解雇 方案， 我们 不 仅 节 省 了 不 少 于 30% 的 开发 成 本 ， 同 时 可 以 将 精力 
更 加 集中 于 业务 本 身 ， 而 且 由 于 Kubernetes 提 供 了 强大 的 自动 化 机 制 ， 
所 以 系统 后 期 的 运 维 难度 和 运 维 成 本 大 幅度 降低 。 











然后 ，Kubernetes 是 一 个 开放 的 开发 平台 。 与 J2EE 不 同 ， 它 不 局 限 
于 任何 一 种 语言 ， 没 有 限定 任何 编程 接口 ， 所 以 不 论 是 用 Java、Go、 
C++ 还 是 用 Python 编写 的 服务 ， 都 可 以 蝶 无 困难 地 映射 为 Kubernetes 的 
Service， 并 通过 标准 的 TCP 通 信 协 议 进 行 交 互 。 此 外 ， 由 于 Kubernetes 
平台 对 现 有 的 编程 语言 、 编 程 框架 、 中 间 件 没有 任何 侵入 性 ， 因 此 现 有 
的 系统 也 很 容易 改造 升级 并 迁移 到 Kubernetes 平 台 上 。 











最 后 ，Kubernetes 是 一 个 完备 的 分 布 式 系 统 支 撑 平 台 。Kubernetes 具 
有 完备 的 集群 管理 能 力 ， 包 括 多 层次 的 安全 防护 和 准 入 机 制 、 多 租户 应 
用 文 撑 能 力 、 透 明 的 服务 注册 和 服务 发 现 机 制 、 内 建 智能 负载 均衡 右 、 
强大 的 故障 发 现 和 自我 修复 能 力 、 服 务 滚动 升级 和 在 线 扩容 能 力 、 可 扩 
展 的 资源 自动 调度 机 制 ， 以 及 多 粒度 的 资源 配额 管理 能 力 。 同 时 ， 
Kubernetes 提 供 了 完善 的 管理 工具 ， 这 些 工 具 涵 盖 了 包括 开发 、 部 署 测 
试 、 运 维 监控 在 内 的 各 个 环节 。 因 此 ，Kubemetes 是 一 个 全 新 的 基于 容 
器 技术 的 分 布 式 架构 解决 方案， 并 且 是 一 个 一 站 式 的 完备 的 分 布 式 系统 
开发 和 支撑 平台 。 








在 正式 开始 本 章 的 Hello World 之 旅 之 前 ， 我 们 首先 要 学 习 
Kubernetes 的 一 些 基本 知识 ， 这 样 我 们 才能 理解 Kubernetes 提 供 的 解决 方 


案 。 


在 Kubernetes 中 ，Service (服务 ) 是 分 布 式 集群 架构 的 核心 ， 一 个 
Service 对 象 拥有 如 下 关键 特征 。 


。 拥 有 一 个 唯一 指定 的 名 字 〈 比 如 mysql-server) 。 

。 拥有 一 个 虚拟 IP (Cluster IP. Service IP 或 VIP) 和 端口 号 。 
。 能 够 提供 某 种 远程 服务 能 

o 被 映射 到 了 提供 这 种 服务 能 力 的 一 组 容器 应 用 上 。 


Service 的 服务 进程 目前 都 基于 Socket 通 信 方 式 对 外 提供 服务 ， 比 如 
Redis, Memcache, MySQL. Web Server， 或 者 是 实现 了 某 个 具体 业务 
的 一 个 特定 的 TCP Server 进 程 。 虽 然 一 个 Service 通 种 由 多 个 相关 的 服务 
进程 来 提供 服务 ， 每 个 服务 进程 都 有 一 个 独立 的 Endpoint 〈IP+Port) 访 
问 点 ， 但 Kubernetes 能 够 让 我 们 通过 Service〈 虚 拟 Cluster IP+Service 
Port) 连接 到 指定 的 Service 上 。 有 了 Kubernetes 内 建 的 透明 负载 均衡 和 
故障 恢复 机 制 ， 不 管 后 端 有 多 少 服务 进程 ， 也 不 管 某 个 服务 进程 是 否 会 
由 于 发 生 故 障 而 重新 部 署 到 其 他 机 器 ， 都 不 会 影响 到 我 们 对 服务 的 正 各 
调用 。 更 重要 的 是 这 个 Service 本 里 一 旦 创建 束 不 再 变化 ， 这 意味 着 ， 在 
Kubernetes 集 群 中 ， 我 们 再 也 不 用 为 了 服务 的 JP 地 址 变 来 变 去 的 问题 而 
头疼 了 。 


容器 提供 了 强大 的 隔离 功能 ， 所 以 有 必要 把 为 Service 提 供 服务 的 这 
组 进程 放 入 容器 中 进行 隔离 。 为 此 ，Kubernetes 设 计 了 Pod 对 象 ， 将 每 个 
服务 进程 包装 到 相应 的 Pod 中 ， 使 其 成 为 Pod 中 运行 的 一 个 容器 
(Container) 。 为 了 建立 Service 和 Pod 间 的 关联 关系 ，Kubernetes 首 先 给 
每 个 Pod 贴 上 一 个 标签 (Label) ， 给 运行 MySQL 的 Pod 贴 上 name=mysql 
标签 ， 给 运行 PHP 的 Pod 贴 上 name=php 标 签 ， 然 后 给 相应 的 Service 定 义 
标签 选择 器 (Label Selector) ， 比 如 MySQL Service 的 标签 选择 器 的 选 
择 条 件 为 name=mysql， 意 为 该 Service 要 作用 于 所 有 包含 name=mysql 


Label 的 Pod 上。 这 样 一 来 ， 就 巧妙 地 解决 了 Service 与 Pod 的 关联 问题 。 


说 到 Pod， 我 们 这 里 先 简单 介绍 其 概念 。 首 和 完 ，Pod 运 行 在 一 个 我 们 
PRZAT (Node) 的 环境 中 ， 这 个 节点 既 可 以 是 物理 机 ， 也 可 以 是 私 
有 云 或 者 公有 云 中 的 一 个 虚拟 机 ， 通 常 在 一 个 节点 上 运行 几 百 个 Pod; 
其 次 ， 每 个 Pod 里 运行 着 一 个 特殊 的 被 称 之 为 Pause 的 容器 ， 其 他 容 右 则 
为 业务 容器 ， 这 些 业 务 容器 共享 Pause 容 器 的 网 络 栈 和 Volume 挂 载 卷 ， 
因此 它们 之 间 的 通信 和 数据 交换 更 为 高 效 ， 在 设计 时 我 们 可 以 充分 利用 
这 一 特性 将 一 组 密切 相关 的 服务 进程 放 入 同一 个 Pod 中 ; 最后， 需要 注 
意 的 是 ， 并 不 是 每 个 pod 和 它 里 面 运行 的 容 需 都 能 “映射 ?到 一 个 Service 
上 ， 只 有 那些 提供 服务 (无 论 是 对 内 还 是 对 外 〉 的 一 组 Pod 才 会 被 “ 映 
SY” TRF 














在 集群 管理 方面 ，Kubernetes 将 集群 中 的 机 器 划分 为 一 个 Master 节 
点 和 一 群 工作 节点 〈Node) 。 其 中 ， 在 Master 节 点 上 运行 着 集群 管理 相 
关 的 一 组 进程 kube-apiserver、kube-controller-manager 和 kube-scheduler， 
这 些 进 程 实现 了 整个 集群 的 资源 管理 、Pod 调 度 、 弹 性 伸缩 、 安 全 控 
制 、 系 统 监控 和 纠 错 等 管理 功能 ， 并 且 都 是 全 上 自动 完成 的 。Node 作 为 集 
群 中 的 工作 节点 ， 运 行 真 正 的 应 用 程序 ， 在 Node 上 Kubernetes 管 理 的 最 
小 运行 单元 是 Pod。Node 上 运行 着 Kubernetes 的 kubelet、kube-proxy 服 务 
进程 ， 这 些 服务 进程 负 贡 Pod 的 创建 、 局 动 、 监 控 、 重 局 、 销 毁 ， 以 及 
实现 软件 模式 的 负载 均衡 器 。 











最 后 ， 我 们 再 来 看 看 传统 的 开 系 统 中 服务 扩容 和 服务 升级 这 两 个 难 
题 ， 以 及 Kubernetes 所 提供 的 全 新 解雇 思路。 服务 的 扩容 涉及 资源 分 配 
《选择 哪个 节点 进行 扩容 ) 、 实 例 部 署 和 启动 等 环节 ， 在 一 个 复杂 的 业 
务 系统 中 ， 这 两 个 问题 基本 上 靠 人 工 一 步 步 操作 才 得 以 完成 ， 费 时 费力 
又 难以 保证 实施 质量 。 











在 Kubernetes 集 群 中 ， 你 只 需 为 需要 扩容 的 Service 关 联 的 Pod 创 建 一 
个 Replication ”Controller〈 简 称 RC) ， 则 该 Service 的 扩容 以 至 于 后 来 的 
Service 升 级 等 头疼 问题 都 迎刃而解 。 在 一 个 RC 定义 文件 中 包括 以 下 3 个 
关键 信息 。 


。 目标 Pod 的 定义 。 
。 目标 Pod 需 要 运行 的 副本 数量 〈Replicas) 。 
。 要 监控 的 目标 Pod 的 标签 (Label) 。 








在 创建 好 RC (系统 将 自动 创建 好 Pod) 后 ，Kubernetes 会 通过 RC 中 
定义 的 Label 筛 选 出 对 应 的 Pod 实 例 并 实时 监控 其 状态 和 数量 ， 如 果实 例 
数量 少 于 定义 的 副本 数量 (Replicas) ， 则 会 根据 RC 中 定义 的 Pod 模 板 
来 创建 一 个 新 的 Pod， 然 后 将 此 Pod 调 度 到 合适 的 Node 上 启动 运行 ， 直 
到 Pod 实 例 的 数量 达到 预定 目标 。 这 个 过 程 完全 是 自动 化 的 ， 无 须 人 工 
干预 。 有 了 RC， 服 务 的 扩容 就 变 成 了 一 个 纯粹 的 简单 数字 游戏 了 ， 只 
要 修改 RC 中 的 副本 数量 即 可 。 后 续 的 Service 升 级 也 将 通过 修改 RC 来 自 
动 完成 。 





以 将 在 第 2 章 介 绍 的 PHP+Redis 留 言 板 应 用 为 例 ， 只 要 为 PHP 留 言 板 
程序 (frontend) 创建 一 个 有 3 个 副本 的 RC+Service， 为 Redis 读 写 分 离 集 
群 创建 两 个 RC: 写 节 点 〈redis-master) 创建 一 个 单 副本 的 RC+Service， 
读 节 点 (redis-slaver) 创建 一 个 有 两 个 副本 的 RC+Service， 就 可 以 分 分 
钟 完成 整个 集群 的 搭建 过 程 了 ， 是 不 是 很 简单 ? 





1.2 ”为 什么 要 用 Kubernetes 


使 用 Kubernetes 的 理由 很 多 ， 最 根本 的 一 个 理由 就 是 : ITM RABE 
一 个 由 新 技术 驱动 的 行业 。 


Docker 这 个 新 兴 的 容器 化 技术 当前 已 经 被 很 多 公司 所 采用 ， 其 从 单 
机 走向 集群 已 成 为 必然 ， 而 云 计 算 的 莲 动 发 展 正在 加 速 这 一 进程 。 
Kubernetes 作 为 当前 唯一 被 业界 广泛 认可 和 看 好 的 Docker 分 布 式 系统 解 
决 方案 ， 可 以 预见 ， 在 未 来 几 年 内 ， 会 有 大 量 的 新 系统 选择 它 ， 不 管 这 
些 系统 是 运行 在 企业 本 地 服务 器 上 还 是 被 托管 到 公有 云 上 。 





使 用 了 Kubernetes 又 会 收获 哪些 好 处 呢 ? 








首先 ， 最 直接 的 感受 就 是 我 们 可 以 “轻装 上 阵 ? 地 开发 复杂 系统 了 。 
以 前 动不动 就 需要 十 几 个 人 而 且 团 队 里 需要 不 少 技 术 达 人 一 起 分 工 协作 
才能 设计 实现 和 运 维 的 分 布 式 系 统 ， 在 采用 Kubernetes 解 决 方案 之 后 ， 
只 需 一 个 精 悍 的 小 团队 就 能 轻松 应 对 。 在 这 个 团队 里 ， 一 名 架构 师 专注 
于 系统 中 “服务 组 件 ” 的 提炼 ， 几 名 开发 工程 师 专注 于 业务 代码 的 开发 ， 
一 名 系统 兼 运 维 工程 师 负 责 Kubernetes 的 部 署 和 运 维 ， 从 此 再 也 不 
用 “996” 了 ， 这 并 不 是 因为 我 们 少 做 了 什么 ， 而 是 因为 Kubernetes 已 经 帮 
我 们 做 了 很 多 。 





其 次 ， 使 用 Kubernetes 束 是 在 全 面 拥 抱 微 服务 架构 。 微 服务 架构 的 
核心 是 将 一 个 巨大 的 单 体 应 用 分 解 为 很 多 小 的 互相 连接 的 微服 务 ， 一 个 
微服 务 背后 可 能 有 多 个 实例 副本 在 文 撑 ， 副 本 的 数量 可 能 会 随 痢 系统 的 
负 蓓 变化 而 进行 调整 ， 内 髓 的 负载 均衡 器 在 这 里 及 挥 了 重要 人 作用。 微服 











务 架 构 使 得 每 个 服务 都 可 以 由 专门 的 开发 团队 来 开发 ， 开 发 者 可 以 自由 
选择 开发 技术 ， 这 对 于 大 规模 团队 来 说 很 有 价值 ， 另 外 每 个 微服 务 独 立 
开发 、 升 级 、 扩 展 ， 因 此 系统 具备 很 高 的 稳定 性 和 快速 迭代 进化 能 

谷歌 、 亚 马 逊 、eBay、NetFlix 等 众多 大 型 互联 网 公司 都 采用 了 微服 务 架 
构 ， 此 次 谷歌 更 是 将 微服 务 染 构 的 基础 设施 直接 打包 到 Kubernetes 解 决 
方案 中 ， 让 我 们 有 机 会 直接 应 用 微服 务 染 构 解 决 复杂 业务 系统 的 染 构 问 
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然后 ， 我 们 的 系统 可 以 随时 随地 整体 “搬迁 ”到 公有 云 上 。 

Kubernetes 最 初 的 目标 就 是 运行 在 谷歌 自家 的 公有 云 GCE 中 ， 未 来 会 文 
持 更 多 的 公有 云 及 基于 OpenStack 的 私有 云 。 同 时 ， 在 Kubernetes 的 架构 
方案 中 ， 压 层 网 络 的 细节 完全 被 屏蔽 ， 基 于 服务 的 Cluster IP 甚 至 都 无 须 
我 们 改变 运行 期 的 配置 文件 ， 就 能 将 系统 从 物理 机 环境 中 无 颖 迁移 到 公 
有 云 中 ， 或 者 在 服务 高 峰 期 将 部 分 服务 对 应 的 Pod 副 本 放 入 公有 云 中 以 
提升 系统 的 吞吐 量 ， 不 仅 节 省 了 公司 的 便 件 投入 ， 还 大 大 改善 了 客户 体 
验 。 我 们 所 熟知 的 铁道 部 的 12306 购 票 系统 ， 在 春节 高 峰 期 承租 用 了 阿 
BATAM: 

















最 后 ，Kubernetes 系 统 架 构 具 备 了 超 强 的 横 回 扩容 能 力 。 对 于 互联 
网 公司 来 说 ， 用 户 规模 就 等 价 于 资产 ， 谁 拥有 更 多 的 用 户 ， 谁 就 能 在 竞 
争 中 胜出 ， 因 此 超 强 的 横 回 扩容 能 力 是 互联 网 业务 系统 的 关键 指标 之 
一 。 不 用 修改 代码 ， 一 个 Kubernetes 集 群 即 可 从 只 包含 几 个 Node 的 小 集 
群 平 滑 扩展 到 拥有 上 百 个 Node 的 大 规模 集群 ， 我 们 利用 Kubernetes 提 供 
的 工具 ， 甚 至 可 以 在 线 完成 集群 扩容 。 只 要 我 们 的 微服 务 设计 得 好 ， 结 
合 便 件 或 者 公有 云 资源 的 线性 增加 ， 系 统 就 能 够 承受 大 量 用 户 并 发 访问 
所 和 带 来 的 巨大 压力 。 











1.3 从 一 个 简单 的 例子 开始 


考虑 到 本 书 第 1 版 中 的 PHP+Redis 留 言 板 的 Hello World 例 子 对 于 绝 大 
多 数 刚 接触 Kubernetes 的 人 来 说 比较 复杂 ， 难 以 顺利 上 手 和 实践 ， 所 以 
我 们 在 此 将 这 个 例子 蔡 换 成 一 个 简单 得 多 的 Java Web 应 用 ， 可 以 让 新 手 
快速 上 手 和 实践 。 


此 Java “Web 应 用 的 结构 比较 简单 ， 是 一 个 运行 在 Tomcat 里 的 Web 
App， 如 图 1.1 所 示 ，JSP 页 面 通 过 JDBC 直 接 访问 MySQL 数 据 库 并 展示 数 
据 。 为 了 演示 和 简化 的 目的 ， 只 要 程序 正确 连接 到 了 数据 库 上 ， 它 就 会 
自动 完成 对 应 的 Table 的 创建 与 初始 化 数据 的 准备 工作 。 所 以 ， 当 我 们 
通过 浏览 器 访问 此 应 用 的 时 候 ， 就 会 显示 一 个 表格 的 页 面 ， 数 据 则 来 自 
数据 库 。 














Java Web App 























Tomcat 


图 1.1 Java Web 应 用 的 架构 组 成 





此 应 用 需要 启动 两 个 容器 : Web App 容 器 和 MySQL 容 器 ， 并 且 Web 
App 容 器 需要 访问 MySQL 容 器 。 在 Docker 时 代 ， 假 设 我 们 在 一 个 宿主 机 
上 启动 了 这 两 个 容器 ， 则 我 们 需要 把 MySQL 容 器 的 IP 地 址 通过 环境 变量 


的 方式 注入 Web App 容 器 里 ; 同时， 需要 将 WebApp 容 器 的 8080 端 口 映 
射 到 宿主 机 的 8080 端 口 ， 以 便 能 在 外 部 访问 。 在 本 章 的 这 个 例子 里 ， 我 
们 看 看 在 Kubernetes 时 代 是 如 何 完 成 这 个 目标 的 。 


1.3.1 环境 准备 


首先 ， 我 们 开始 准备 Kubernetes 的 安装 和 相关 镜像 下 载 ， 本 书 建议 
采用 VirtualBox 或 者 VMwareWorkstation 在 本 机 虚拟 一 个 64 位 的 CentOS 7 
虚拟 机 作为 学 习 环 境 ， 虚 拟 机 采用 NAT 的 网 络 模式 以 便 能 够 连接 外 网 ， 
然后 按照 以 下 步骤 快速 安装 Kubernetes。 


(1) 关闭 CentOS 自 带 的 防火 墙 服 务 : 


# systemctl disable firewalld 


# systemctl stop firewalld 


(2) 安装 etcd 和 Kubernetes 软 件 〈 会 自动 安装 Docker 软 件 ) : 


#yum install -y etcd kubernetes 


(3) 安装 好 软件 后 ， 修 改 两 个 配置 文件 《其 他 配置 文件 使 用 系统 
默认 的 配置 参数 即 可 )〉。 


。 Docker 配 置 文件 为 /etc/sysconfig/docker， 其 中 OPTIONS 的 内 容 设 置 
为 : 


OPTIONS='--selinux-enabled=false --insecure-registry gcr 


e Kubernetes apiserver 配 置 文件 为 /etc/kubernetes/apiserver， 把 -- 
admission_control 参 数 中 的 ServiceAccount 删 除 。 


(4) 按 顺 序 局 动 所 有 的 服务 : 


#systemctl start etcd 

#systemctl start docker 

#systemctl start kube-apiserver 
#systemctl start kube-controller-manager 
#systemctl start kube-scheduler 
#systemctl start kubelet 


#systemctl start kube-proxy 





至 此 ， 一 个 单机 版 的 Kubernetes 集 群 环境 就 安装 启动 完成 了 。 
接 下 来 ， 我 们 可 以 在 这 个 单机 版 的 Kubernetes 集 群 中 上 手 练习 了 。 


注 : 本 书 示例 中 的 Docker 镜 像 下 载 地 址 为 
https://hub.docker.com/u/kubeguide/. 


1.3.2 ”局 动 MySQL 服 务 


首先 为 MYSQL 服务 创 建 一 个 RC 定 义 文 件 : mysql-rc.yaml， 下 面 给 
出 了 该 文件 的 完整 内 容 和 人 解释， 如 图 1.2 所 示 。 


apiVersion: vl 


kind: ReplicationController 一 一 一 一 一 一 副本 控制 器 rc 
metadata: 
name: mysql 一 一 RC 的 名 称 ， 全 局 唯一 
spec: 
replicas: 1 — pod 副本 期 待 数量 
selector: 
app: mysql 一 一 一 一 一 一 符合 目标 的 Pod 拥有 此 标签 
template: 一 一 一 一 一 一 根据 此 模板 创建 Pod 的 副本 (实例 》 
metadata: 
labels: 
app: mysql 一 一 一 一 一 一 Pod 副本 拥有 的 标签 ， 对 应 RC 的 Selector 
spec: 
containers: 一 一 一 一 一 Pod 内 容器 的 定义 部 分 
- name: mysql 一 一 一 一 一 容器 的 名 称 
image: mysql 一 一 一 一 一 一 容器 对 应 的 Docker Image 
ports: 
- containerPort: 3306 一 一 一 一 一 一 容器 暴露 的 端口 号 
env: 一 一 一 一 一 注入 到 容器 内 的 环境 变量 


- name: MYSQL ROOT PASSWORD 
value: "123456" 


图 1.2 ”RC 的 定义 和 解说 图 


yaml 定 义 文件 中 的 kind 属 性 ， 用 来 表明 此 资源 对 象 的 类 型 ， 比 如 这 
里 的 值 为 “ReplicationController”"”， 表 示 这 是 一 个 RC;，spec 一 节 中 是 RC 的 
相关 属性 定义 ， 比 如 spec.selector 是 RC 的 Pod 标 签 (Label) 选择 器 ， 即 
监控 和 管理 拥有 这 些 标签 的 Pod 实 例 ， 确 保 当前 集群 上 始终 有 且 仅 有 
replicas 个 Pod 实 例 在 运行 ， 这 里 我 们 设置 replicas=1 表 示 只 能 运行 一 个 
MySQL ”Pod 实 例 。 当 集群 中 运行 的 Pod 数 量 小 于 replicas 时 ，RC 会 根据 
spec.template 一 节 中 定义 的 Pod 模 板 来 生成 一 个 新 的 Pod 实 例 ， 
spec.template.metadata.labels 指 定 了 该 Pod 的 标签 ， 需 要 特别 注意 的 是 : 





这 里 的 labels 必 须 匹 配 之 前 的 spec.selector， 人 否则 此 RC 每 次 创建 了 一 个 无 
法 匹配 Label 的 Pod， 束 会 不 停 地 答 试 创建 新 的 Pod， 最 终 陷 入 “只 为 他 人 
做 退 衣 ”的 悲惨 世界 中 ， 永 无 翻 身 之 时 。 


创建 好 redis-master-controller.yaml 文 件 以 后 ， 为 了 将 它 发 布 到 
Kubernetes 集 群 中 ， 我 们 在 Master 节 点 执行 命令 : 


# kubectl create -f mysql-rc.yaml 


replicationcontroller "mysql" created 


接 下 来 ， 我 们 用 kubectl 命 令 查看 刚刚 创建 的 RC: 


# kubectl get rc 
NAME DESIRED CURRENT AGE 


mysql 1 1 7m 








查看 Pod 的 创建 情况 时 ， 可 以 运行 下 面 的 命令 : 


# kubectl get pods 
NAME READY STATUS RESTARTS AGE 


mysql-c95jc 1/1 Running 0 91 


我 们 看 到 一 个 名 为 mysql-xxxxx 的 Pod 实 例 ， 这 是 Kubernetes 根 据 
mysql 这 个 RC 的 定义 自动 创建 的 Pod。 由 于 Pod 的 调度 和 创建 需要 花费 一 
定 的 时 间 ， 比 如 需要 一 定 的 时 间 来 确定 调度 到 哪个 节点 上 ， 以 及 下 载 
Pod 里 容器 的 镜像 需要 一 段 时 间 ， 所 以 一 开始 我 们 看 到 Pod 的 状态 将 显示 
为 Pending。 当 Pod 成 功 创建 完成 以 后 ， 状 态 最 终 会 被 更 新 为 Running。 








我 们 通过 docker ps 指令 查看 正在 运行 的 容器 ， 发 现 提 供 MySQL 服 务 
的 Pod 容 器 已 经 创建 并 正常 运行 了 ， 此 外 ， 你 会 发 现 MySQL Pod 对 应 的 
容器 还 多 创建 了 一 个 来 自 谷 歌 的 pause 容 器 ， 这 就 是 Pod 的 “ 根 容器 >”， 详 
见 1.4.3 芒 的 说 明 。 


# docker ps |grep mysql 
72ca992535b4 mysql 


76c1790aad27 gcr.io/google_containers/pause-amd64 


最 后 ， 我 们 创建 一 个 与 之 关联 的 Kubernetes Service 一 一 MySQL 的 定 
义 文件 (文件 名 为 mysql-svc.yaml) ， 完 整 的 内 容 和 解释 如 图 1.3 所 示 。 





apiVersion: vl 


kind: Service 一 一 一 一 一 表明 是 Kubernetes Service 
metadata: 
name: mysql — service 的 全 局 唯一 名 称 
spec: 
POLES: 
- port: 3306 一 一 一 一 Service 提供 服务 的 端口 号 
selector: 一 Service 对 应 的 Pod 拥有 这 里 定义 的 标签 
app: mysql 


图 1.3 ”Service 的 定义 和 解说 图 


其 中 ，metadata.name 是 Service 的 服务 名 (ServiceName) ; port 属 性 
则 定义 了 Service 的 虚 端 口 ; spec.selector 确 定 了 哪些 Pod 副 本 (实例 ) 对 
应 到 本 服务 。 类 似 地 ， 我 们 通过 kubectl create 命 令 创 建 Service 对 象 。 


运行 kubectl 命 令 ， 创 建 service: 


# kubectl create -f mysql-svc.yaml 


service "mysql" created 


运行 kubectl 命 令 ， 可 以 查看 到 刚刚 创建 的 service: 


# kubectl get svc 
NAME CLUSTER- IP EXTERNAL - IP PORT(S) 


mysql 169.169.253.143 <none> 3306/TCP 


注意 到 MySQL 服 务 被 分 配 了 一 个 值 为 169.169.253.143 的 ClusterIP 地 
址 ， 这 是 一 个 虚 地 址 ， 随 后 ，Kubernetes 集 群 中 其 他 新 创建 的 Pod 就 可 以 
通过 Service 的 ClusterIP+ 端 口号 6379 来 连接 和 访问 它 了 。 


在 通常 情况 下 ，ClusterIP 是 在 Service 创 建 后 由 Kubernetes 系 统 自 动 
分 配 的 ， 其 他 Pod 无 法 预先 知道 某 个 Service 的 ClusterIP 地 址 ， 因 此 需要 
一 个 服务 发 现 机 制 来 找到 这 个 服务 。 为 此 ， 最 初 的 时 候 ，Kubernetes 巧 
妙 地 使 用 了 Linux 环 境 变量 (Environment Variable) 来 解决 这 个 问题 ， 
后 面 会 详细 说 明 其 机 制 。 现 在 我 们 只 需 知 道 ， 根 据 Service 的 唯一 名 字 ， 
容器 可 以 从 环境 变量 中 获取 到 Service 对 应 的 Cluster IP 地 址 和 端口 ， 从 而 
发 起 TCP/IP 连 接 请 求 了 。 








1.3.3 ”局 动 Tomcat 心 用 


上 面 我 们 定义 和 启动 了 MySQL 服 务 ， 接 下 来 我 们 采用 同样 的 步 
又 ， 完 成 Tomcat 应 用 的 启动 过 程 。 首 先 ， 创 建 对 应 的 RC 文件 myweb- 
rc.yaml， 内 容 如 下 : 


kind: ReplicationController 
metadata: 
name: myweb 
spec: 
replicas: 5 
selector: 
app: myweb 
template: 
metadata: 
labels: 
app: myweb 
spec: 
containers: 
- name: myweb 
image: kubeguide/tomcat-app:v1 
ports: 
- containerPort: 8080 


env: 


- name: MYSQL_SERVICE_HOST 
value: 'mysql' 
- name: MYSQL_SERVICE_PORT 


value: '3306' 





注意 到 上 面 RC 对 应 的 Tomcat 容 器 里 引用 了 


MYSQL_SERVICE_HOST=mysql 这 个 环境 变量 ， 而 “mysql 恰 好 是 我 们 
之 前 定义 的 MySQL 服 务 的 服务 名 ， 运 行 下 面 的 命令 ， 完 成 RC 的 创建 和 





验证 工作 : 


#kubectl create -f myweb-rc.yaml 


replicationcontroller "myweb" created 


#kubectl get pods 


NAME READY STATUS RESTARTS 
mysql-c95jc 1/1 Running 0 2h 
myweb-g9pmm 1/1 Running 0 3s 


最 后 ， 创 建 对 应 的 Service。 以 下 是 完整 的 yaml 定 义 文 件 (myweb- 


svc.yaml) : 


apiVersion: v1 
kind: Service 
metadata: 

name: myweb 
spec: 


type: NodePort 


ports: 
- port: 8080 
nodePort: 30001 
selector: 


app: myweb 


注意 type=NodePort 和 nodePort=30001 的 两 个 属性 ， 表 明 此 Service 开 
局 人 在 Kubernetes 集 群 之 外 ， 比 如 在 本 
机 的 浏览 器 里 ， 可 以 通过 30001 这 个 端口 访问 myweb〔 对 应 到 8080 的 虚 
端口 上 ) 。 


运行 kubectl create 命 令 进行 创建 : 


# kubectl create -f myweb-svc.yaml 

You have exposed your service on an external port on all 
cluster. If you want to expose this service to the exte 
need to set up firewall rules for the service port(s) (t 
See http://releases.k8s.i0/release-1.3/docs/user -guide/si 


service "myweb" created 








我 们 看 到 上 面 有 提示 信息 ， 意 思 是 需要 把 30001 这 个 端口 在 防火 墙 
上 打开 ， 以 便 外 部 的 访问 能 穿 过 防火 墙 


运行 kubectl 命 令 ， 查 看 创建 的 Service: 


# kubectl get services 


NAME CLUSTER- IP EXTERNAL - IP PORT(S) 
mysql 169.169.253.143 <none> 3306/TCP 


myweb 169.169.149.215 <nodes> 8080/TCP 


kubernetes 169.169.0.1 <none> 443/TC 


至 此 ， 我 们 的 第 1 个 Kubernetes 例 子 搭建 完成 了 ， 在 下 一 节 中 我 们 验 
证 结果 。 


1.3.4 ”通过 浏览 器 访问 网 页 


经 过 上 面 的 几 个 步 又， 我 们 终于 成 功 实现 了 Kubernetes 上 第 1 个 例子 
的 部 署 搭建 工作 。 现 在 一 起 来 见证 成 果 吧 ， 在 你 的 笔记 本 上 打开 浏览 
器 ， 输 入 http:// 虚 拟 机 IP: 30001/demo/。 





比如 虚 机 IP 为 192.168.18.131〔( 可 以 通过 #ip a 命令 进行 查询 ) ， 在 浏 
览 器 里 输入 地 址 http://192.168.18.131: 30001/demo/ 后 ， 看 到 了 如 图 1.4 所 
示 的 网 页 界面 ， 那 么 茶 喜 你 ， 之 前 的 努力 没有 白费 ， 顺 利 阅 关 成 功 ! 








Congratulations!! 


Add 





Name Level (Score) 
google 100 
docker 100 
100 

PE 100 
Dur team 100 
me 100 
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图 1.4 通过 浏览 器 访问 Tomcat 心 用 


如 有 果 看 不 到 这 个 网 页 ， 那 么 可 能 有 几 个 原因 : 比如 防火 墙 的 问题 ， 
无 法 访问 30001 端 口 ， 或 者 因为 你 是 通过 代理 上 网 的 ， 浏 览 器 错 把 虚拟 
机 的 IP 地 址 当成 远程 地 址 了 。 可 以 在 虚拟 机 上 直接 运行 curl localhost: 
30001 来 验证 此 端口 是 否 能 被 访问 ， 如 宁 还 是 不 能 访问 ， 那 么 这 肯定 不 
是 机 器 的 问题 ..………. 





接 下 来 可 以 尝试 单 击 “Add...” 按 钮 添加 一 条 记录 并 提交 ， 如 图 1.5 所 


示 ， 提 交 以 后 ， 数 据 束 被 号 入 MySQL 数 据 库 中 了 。 


至 此 ， 我 们 终于 完成 了 Kubernetes 上 的 Tomcat 例 子 ， 这 个 例子 并 不 
是 很 复杂 。 我 们 也 看 到 ， 相 对 于 传统 的 分 布 式 应 用 的 部 署 方式 ， 在 
Kubernetes 之 上 我 们 仅仅 通过 一 些 很 容易 理解 的 配置 文件 和 相关 的 简单 
命令 就 完成 了 对 整个 集群 的 部 署 ， 这 让 我 们 恢 证 于 Kubernetes 的 创新 和 
强大 。 


Please input your info 


Your name: [Mag 


Your Level: |100 


Cancel | Submit | 





图 1.5 在 留言 板 网 页 添加 新 的 留言 


下 一 节 ， 我 们 将 开始 对 Kubernetes 中 的 基本 概念 和 术语 进行 全 面 学 
习 ， 在 这 之 前 ， 读 者 可 以 继续 研究 下 这 个 例子 里 的 一 些 拓展 内 容 ， 如 下 
所 述 。 


。 研究 RC、Service 等 文件 的 格式 。 

e 熟悉 kubectl 的 子 命令 。 

。 手工 停止 某 个 Service 对 应 的 容器 进程 ， 然 后 观察 有 什么 现象 发 生 。 
。 修改 RC 文 件 ， 改 变 副 本 数量 ， 重 新 发 布 ， 观 察 结 果 。 





1.4 Kubernetes 基 本 概念 和 术语 


Kubernetes 中 的 大 部 分 概念 如 Node、Pod、ReplicationController、 
Service 等 都 可 以 看 作 一 种 “资源 对 象 ”， 几 乎 所 有 的 资源 对 象 都 可 以 通过 
Kubernetes 提 供 的 kubectl 工 具 (或 者 API 编 程 调用 ) 执行 增 、 删 、 改 、 查 
等 操作 并 将 其 保存 在 etcd 中 持久 化 存储 。 从 这 个 角度 来 看 ，Kubernetes 
其 实 是 一 个 高 度 自动 化 的 资源 控制 系统 ， 它 通过 跟踪 对 比 etcd 库 里 保存 
的 “资源 期 望 状态 ”与 当前 环境 中 的 “实际 资源 状态 ”的 差异 来 实现 自动 控 
制 和 自动 纠 错 的 高 级 功能 。 








1.4.1 Master 





Kubernetes 里 的 Master 指 的 是 集群 控制 节点 ， 每 个 Kubernetes 集 群 里 
需要 有 一 个 Master 节 点 来 负责 整个 集群 的 管理 和 控制 ， 基 本 上 
Kubernetes 所 有 的 控制 命令 都 是 发 给 它 ， 它 来 负责 具体 的 执行 过 程 ， 我 
们 后 面 所 有 执行 的 命令 基本 都 是 在 Master 节 点 上 运行 的 。Master 节 点 通 
常会 占据 一 个 独立 的 X86 服务 器 (或 者 一 个 虚拟 机 〉 ， 一 个 主要 的 原因 
是 它 太 重要 了 ， 它 是 整个 集群 的 “首脑 *"， 如 果 它 宕 机 或 者 不 可 用 ， 那 么 
我 们 所 有 的 控制 命令 都 将 失效 。 





Master 节 点 上 运行 着 以 下 一 组 关键 进程 。 


Kubernetes API Server (kube-apiserver) ， 提 供 了 HTTP Rest 接 口 的 
关键 服务 进程 ， 是 Kubernetes 里 所 有 资源 的 增 、 删 、 改 、 碍 等 操作 
的 唯一 入 口 ， 也 是 集群 控制 的 入 口 进 程 。 

Kubernetes Controller Manager (kube-controller-manager) , 
Kubernetes 里 所 有 资源 对 象 的 自动 化 控制 中 心 ， 可 以 理解 为 资源 对 
象 的 “大 总 管 ”。 

Kubernetes Scheduler (kube-scheduler) ， 人 负责 资源 调度 (Pod 调 
E) 的 进程 ， 相 当 于 公交 公司 的 “调度 室 ”。 





其 实 Master 闻 点 上 往往 还 启动 了 一 个 etcd Server 进 程 ， 因 为 
Kubernetes 里 的 所 有 资源 对 象 的 数据 全 部 是 保存 在 etcd 中 的 。 





1.4.2 Node 


除了 Master，Kubernetes 集 群 中 的 其 他 机 器 被 称 为 Node 市 点 ， 在 较 
早 的 版 本 中 也 被 称 为 Minion。 与 Master 一 样 ，Node 节 点 可 以 是 一 台 物 理 
主机 ， 也 可 以 是 一 台 虚 拟 机 。Node 节 点 才 是 Kubernetes 集 群 中 的 工作 负 
载 节 点 ， 每 个 Node 都 会 被 Master 分 配 一 些 工作 负载 (Docker ir) » 4 
某 个 Node 宕 机 时 ， 其 上 的 工作 负载 会 被 Master 自 动 转移 到 其 他 节点 上 
ae 


BES Node i A EENE TE A BAR EERE 





e kubelet: 负责 Pod 对 应 的 容器 的 创建 、 启 停 等 任务 ， 同 时 与 Master 
点 密切 协作 ， 实 现 集群 管理 的 基本 功能 

kube-proxy: 实现 Kubernetes Service ss 与 负载 均衡 机 制 的 重要 
组 件 。 

Docker Engine (docker) : Docker 引 擎 ， 负 责 本 机 的 容 需 创建 和 管 
MTI 








Node 节 点 可 以 在 运行 期 间 动 态 增加 到 Kubernetes 集 群 中 ， 前 提 是 这 
个 节点 上 已 经 正确 安装 、 配 置 和 启动 了 上 述 关 键 进程 ， 在 默认 情 
kubelet 会 同 Master 注 册 上 自己 ， 这 也 是 Kubernetes 推 荐 的 Node 管 理 方式 。 
一 旦 Node 被 纳入 集群 管理 范围 ，kubelet 进 程 就 会 定时 间 Master 节 点 汇报 
自身 的 情报 ， 例 如 操作 系统 、Docker 版 本 、 机 器 的 CPU 和 内 存 情 况 ， 以 
及 之 前 有 哪些 Pod 在 运行 等 ， 这 样 Master 可 以 获知 每 个 Node 的 资源 使 用 
情况 ， 并 实现 高 效 均衡 的 资源 调度 策略 。 而 某 个 Node 超 过 指定 时 间 不 上 


报信 息 时 ， 会 被 Master 判 定 为 “ 失 联 ”，Node 的 状态 被 标记 为 不 可 用 
(Not Ready) ， 随 后 Master 会 触发 “工作 负载 大 转移 ”的 自动 流程 。 


我 们 可 以 执行 下 述 命令 查看 集群 中 有 和 多少 个 Node: 


# kubectl get nodes 
NAME STATUS AGE 


kubernetes-minion1 Ready 2d 


然后 ， 通 过 kubectl describe node<node_name> 来 查看 某 个 Node 的 详 


$ kubectl describe node kubernetes-minion1 
Name: k8s-node-1 
Labels: beta. kubernetes.io/arch=amd64 


beta. kubernetes.i0/os=linux 
kubernetes.io0/hostname=k8s -node-1 
Taints: <none> 
CreationTimestamp: Wed, 06 Jul 2016 11:46:41 +0800 
Phase: 
Conditions: 
Type Status LastHeartbeatTime 
MemoryPressure False Sat, 09 Jul 2016 08:17:39 +08 
Ready True Sat, 09 Jul 2016 08:1 
Addresses: 192.168.18.131,192.168.18.131 


Capacity: 


alpha.kubernetes.io/nvidia-gpu: 


Cpu: 
memory: 
pods: 

Allocatable: 


alpha. kubernetes.i0/nvidia-gpu: 


Cpu: 
memory: 
pods: 
System Info: 
Machine ID: 
System UUID: 
Boot ID: 
Kernel Version: 
OS Image: 
Operating System: 
Architecture: 
Container Runtime Version: 
Kubelet Version: 
Kube-Proxy Version: 
ExternalID: 
Non-terminated Pods: 
Namespace 
kube-system 


Allocated resources: 


0 
4 
1868692Ki 
110 
0 
4 
1868692K1i 
110 


6e4e2af 2afeb42b9aac47i 


564D63D3 - 9664-3393 -A3l 


bOc34f9fF -76ab-478e-9771-bd4fe 


3.10.0-327.22.2.e17.x86_64 


CentOS Linux 7 (Core) 


linux 


v1.3.0 


amd64 


docker://1.11.2 


v1.3.0 
k8s-node-1 
(1 in total) 


Name 


kube-dns-v11-wxdhf 


(Total limits may be over 100 percent, i.e., overcommi 


CPU Requests CPU Limits Memory Reques 
310m (7%) 310m (7%) 170Mi (9%) 170Mi (9%) 


No events. 


上 述 命令 展示 了 Node 的 如 下 关键 信息 。 


Node 基 本 信息 : 名 称 、 标 签 、 创 建 时 间 等 。 

Node 当 前 的 运行 状态 ，Node 局 动 以 后 会 做 一 系列 的 自 检 工作 ， 比 

如 磁盘 是 否 满 了 ， 如 果 满 了 就 标注 OutOfDisk=True， 否 则 继续 检查 
内 存 是 否 不 足 (MemoryPressure=True) ， 最 后 一 切 正 常 ， 就 切换 

为 Ready 状 态 (Ready=True) ， 这 种 情况 表示 Node 处 于 健康 状态 ， 

可 以 在 其 上 创建 新 的 Pod。 

Node 的 主机 地 址 与 主机 名 。 

Node 上 的 资源 总 量 : 描述 Node 可 用 的 系统 资源 ， 包 括 CPU、 内 存 

数量 、 最 大 可 调度 Pod 数 量 等 ， 注 意 到 目前 Kubemetes 已 经 实验 性 地 
支持 GPU 资 源 分 配 了 (alpha.kubernetes.io/nvidia-gpu=0) 。 

Node 可 分 配 资 源 量 : 摘 述 Node 当 前 可 用 于 分 配 的 资源 量 。 

主机 系统 信息 : 包括 主机 的 唯一 标识 UUID、Linux kernel 版 本 号 、 
操作 系统 类 型 与 版 本 、Kubernetes 厂 本 号 、kubelet 与 kube-proxy 的 版 
本 与 等 。 

当前 正在 运行 的 Pod 列 表 概 要 信息 。 

已 分 配 的 资源 使 用 概要 信息 ， 例 如 资源 申请 的 最 低 、 最 大 允许 使 用 
量 占 系 统 总 量 的 百分比 。 

Node 相 关 的 Event 信 息 。 








1.4.3 Pod 


Pod 是 Kubernetes 的 最 重要 也 最 基本 的 概念 ， 如 网 1.6 所 示 是 Pod 的 组 
成 示意 图 ， 我 们 看 到 每 个 Pod 都 有 一 个 特殊 的 被 称 为 “ 根 容 器 ”的 Pause 容 
器 。Pause 容 器 对 应 的 镜像 属于 Kubernetes 平 台 的 一 部 分 ， 除 了 Pause 容 
器 ， 每 个 Pod 还 包含 一 个 或 多 个 桶 密 相 关 的 用 户 业 务 容 占 。 

Pod 
Pause 
gcr.io/google_containers/pause-amd64 
user conainter 1 
xxxlmage 








user conainter 2 
xxxlmage 


user conainter N 
xxxlmage 





图 1.6 ”Pod 的 组 成 与 容器 的 关系 


为 什么 Kubernetes 会 设计 出 一 个 全 新 的 Pod 的 概念 并 且 Pod 有 这 样 特 
殊 的 组 成 结构 ? 


原因 之 一 : 在 一 组 容器 作为 一 个 单元 的 情况 下 ， 我 们 难以 对 “ 整 


体 ” 人 简单 地 进行 判断 及 有 效 地 进行 行动 。 比 如 ， 一 个 容器 死亡 了 ， 此 时 
算是 整体 死亡 么 ?是 N/M 的 死亡 率 么 ?引入 业务 无 关 并 且 不 易 死 亡 的 
Pause 容 器 作为 Pod 的 根 容器 ， 以 它 的 状态 代表 整个 容器 组 的 状态 ， 束 人 简 
单 、 巧 妙 地 解雇 了 这 个 难题 。 


原因 之 二 : Pod 里 的 多 个 业务 容器 共享 Pause 容 器 的 IP， 共 享 Pause 容 
器 挂 接 的 Volume， 这 样 既 简 化 了 密切 关联 的 业务 容器 之 间 的 通信 问 
题 ， 也 很 好 地 解决 了 它们 之 间 的 文件 共享 问题 。 


Kubernetes 为 每 个 Pod 都 分 配 了 唯一 的 IP 地 址 ， 称 之 为 Pod JP， 一 个 
Pod 里 的 多 个 容器 共享 Pod IP 地 址 。Kubernetes 要 求 底 层 网 络 支 持 集群 内 
任意 两 个 Pod 之 间 的 TCP/IP 直 接 通 信 ， 这 通常 采用 虚拟 二 层 网 络 拉 术 来 
实现 ， 例 如 Flannel、Openvswitch 等 ， 因 此 我 们 需要 牢记 一 点 : 在 
Kubernetes 里 ， 一 个 Pod 里 的 容器 与 男 外 主机 上 的 Pod 容 器 能 够 直接 通 


ES 
信 。 


Pod 其 实 有 两 种 类 型 : 普通 的 Pod 及 静态 Pod (static Pod) ， 后 者 比 
较 特 殊 ， 它 并 不 存放 在 Kubernetes 的 etcd 存 储 里 ， 而 是 存放 在 某 个 具体 
的 Node 上 的 一 个 具体 文件 中 ， 并 且 只 在 此 Node 上 启动 运行 。 而 普通 的 
Pod 一 旦 被 创建 ， 天 会 被 放 入 到 etcd 中 存储 ， 随 后 会 被 Kubernetes Master 
调度 到 某 个 具体 的 Node 上 并 进行 绑 定 (Binding) ， 随 后 该 Pod 被 对 应 的 
Node 上 的 kubelet 进 程 实例 化 成 一 组 相关 的 Docker 容 器 并 启动 起 来 。 在 默 
认 情 况 下 ， 当 Pod 里 的 某 个 容器 停止 时 ，Kubernetes 会 目 动 检测 到 这 个 问 
题 并 且 重 新 启动 这 个 Pod (重启 Pod 里 的 所 有 容器 ) ， 如 果 Pod 所 在 的 
Node 宕 机 ， 则 会 将 这 个 Node 上 的 所 有 Pod 重 新 调度 到 其 他 节点 上 。 
Pod、 容 器 与 Node 的 关系 如 图 1.7 所 示 。 
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图 1.7 Pod、 容 器 与 Node 的 关系 


Kubernetes 里 的 所 有 资源 对 象 都 可 以 采用 yaml 或 者 JSON 格 式 的 文件 
来 定义 或 描述 ， 下 面 是 我 们 在 之 前 Hello World 例 子 里 用 到 的 myweb 这 个 
Pod 的 资源 定义 文件 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: myweb 
labels: 
name: myweb 
spec: 
containers: 
- name: myweb 
image: kubeguide/tomcat -app:v1 


ports: 


- containerPort: 8080 

env: 

- name: MYSQL_SERVICE_HOST 
value: 'mysql' 

- name: MYSQL_SERVICE_PORT 
value: '3306' 


Kind 为 Pod 表 明 这 是 一 个 Pod 的 定义 ，metadata 里 的 name 属 性 为 Pod 
的 名 字 ，metadata 里 还 能 定义 资源 对 象 的 标签 (Labe ， 这 里 声明 
myweb 拥 有 一 个 hame=myweb 的 标签 (Label) 。Pod 里 所 包含 的 容器 组 
的 定义 则 在 spec 一 节 中 声明 ， 这 里 定义 了 一 个 名 字 为 myweb、 对 应 镜像 
为 kubeguide/tomcat-app: V1 的 容器 ， 该 容 右 注入 了 名 为 
MYSQL_SERVICE_HOST=‘mysql’ il 
MYSQL_SERVICE_PORT=“3306’ 的 环境 变量 〈env 关 键 字 ) » JF ALE 
8080%m Œ (containerPort〉 上 启动 容器 进程 。Pod 的 IP 加 上 这 里 的 容器 端 
[1 CcontainerPort) ， 就 组 成 了 一 个 新 的 概念 一 一 Endpoint， 它 代表 着 此 
Pod 里 的 一 个 服务 进程 的 对 外 通信 地 址 。 一 个 Pod 也 存在 着 具有 多 个 
Endpoint 的 Te 比如 当 我 们 把 Tomcat 定 义 为 一 个 Pod 的 时 候 ， 可 以 对 
外 暴露 管理 端口 与 服务 端口 这 两 个 Endpoint。 











我 们 所 熟悉 的 Docker ”Volume 在 Kubernetes 里 也 有 对 应 的 概念 
Pod Volume， 后 者 有 一 些 扩 展 ， 比 如 可 以 用 分 布 式 文件 系统 GlusterFS 实 
现 后 端 存 储 功 能 ，Pod Volume 是 定义 在 Pod 之 上 ， 然 后 被 各 个 容器 挂 载 
到 自己 的 文件 系统 中 的 。 











这 里 顺便 提 一 下 Kubernetes 的 Event 概 念 ，Event 是 一 个 事件 的 记 
录 ， 记 录 了 事件 的 最 早产 生 时 间 、 最 后 重 现时 间 、 重 复 次 数 、 发 起 者 、 





类 型 ， 以 及 导致 此 事件 的 原因 等 众多 信息 。Event 通 常会 关联 到 某 个 具 

体 的 资源 对 象 上 ， 是 排查 故障 的 重要 参考 信息 ， 之 前 我 们 看 到 Node 的 描 
述 信息 包括 了 Event， 而 Pod 同 样 有 Event 记 录 ， 当 我 们 发 现 某 个 Pod 迟 迟 
无 法 创建 时 ， 可 以 用 kubectl describe pod xxxx 来 查看 它 的 描述 信息 ， 用 
来 定位 问题 的 原因 ， 比 如 下 面 这 个 Event 记 录 信 息 表明 Pod 里 的 一 个 容器 
被 探 针 检测 为 失败 一 次 : 


Events: 
FirstSeen LastSeen Count From 
10h 12m 32 {kubelet k8s 





每 个 Pod 都 可 以 对 其 能 使 用 的 服务 器 上 的 计算 资源 设置 限额 ， 当 前 
可 以 设置 限额 的 计算 资源 有 CPU 与 Memory 两 种 ， 其 中 CPU 的 资源 单位 
为 CPU (Core) 的 数量 ， 是 一 个 绝对 值 而 非 相对 值 。 


一 个 CPU 的 配额 对 于 绝 大 多 数 容器 来 说 是 相当 大 的 一 个 资源 配额 
了 ， 所 以 ， 在 Kubernetes 里 ， 通 常 以 干 分 之 一 的 CPU 配 额 为 最 小 单位 ， 
用 m 来 表示 。 通 常 一 个 容器 的 CPU 配 额 被 定义 为 100~~300m， 即 占用 0.1 
一 0. Age Ue 由 于 CPU 配额 是 一 个 绝对 值 ， 所 以 无 论 在 拥有 一 个 Core 的 
机 器 上 ， 还 是 在 拥有 48 个 Core 的 机 器 上 ，100m 这 个 配额 所 代表 的 CPU 的 
使 用 量 都 是 一 样 的 。 与 CPU 配额 类 似 ，Memory 配 额 也 是 一 个 绝对 值 ， 
它 的 单位 是 内 存 字 节 数 。 











在 Kubernetes 里 ， 一 个 计算 资源 进行 配额 限定 需要 设 定 以 下 两 个 参 
数 。 


。 Requests: 该 资源 的 最 小 申请 量 ， 系 统 必须 满足 要 求 。 


e Limits: 该 资源 最 大 人 允许 使 用 的 量 ， 不 能 被 突破 ， 当 容 右 试图 使 用 
超过 这 个 量 的 资源 时 ， 可 能 会 被 Kubernetes K 训 并 重启 。 





通常 我 们 会 把 Request 设 置 为 一 个 比较 小 的 数值 ， 符 合 容 器 平时 的 
工作 负载 情况 下 的 资源 需求 ， 而 把 Limit 设 置 为 峰值 负载 情况 下 资源 占 
用 的 最 大 量 。 比 如 下 面 这 段 定义 ， 表 明 MySQL 容 器 申请 最 少 0.25 个 CPU 
及 64MiB 内 存 ， 在 运行 过 程 中 MySQL 容 器 所 能 使 用 的 资源 配额 为 0.5 个 
CPU 及 128MiB 内 存 : 





spec: 
containers: 
- name: db 
image: mysql 
resources: 
requests: 
memory: "64Mi" 
cpu: "250m" 
limits: 
memory: "128Mi" 


cpu: "500m" 


本 节 最 后 ， 笔 者 给 出 Pod 及 Pod 周 边 对 象 的 示意 图 作为 总 结 ， 如 图 
1.8 所 示 ， 后 面部 分 还 会 涉及 这 张 图 里 的 对 象 和 概念 ， 以 进一步 加 强 理 
解 。 
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图 1.8 Pod 及 周边 对 象 


1.4.4 Label (标签 ) 


Label 是 Kubernetes 系 统 中 另外 一 个 核心 概念 。 了 
key=value 的 键 值 对 ， 其 中 key 与 value 由 用 户 自 己 指定 。Label 可 以 附加 到 
各 种 资源 对 象 上 ， 例 如 Node、Pod、Service、RC 等 ， 一 个 资源 对 象 可 以 
定义 任意 数量 的 Label， 同 一 个 Label 也 可 以 被 添加 到 任意 数量 的 资源 对 
象 上 去 ，Label 通 第 在 资源 对 象 定 义 时 确定 ， 也 可 以 在 对 象 创 建 后 动态 
添加 或 者 删除 。 





我 们 可 以 通过 给 指定 的 资源 对 象 捆绑 一 个 或 多 个 不 同 的 Label 来 实 
现 多 维度 的 资源 分 组 管理 功能 ， 以 便于 灵活 、 方 便 地 进行 资源 分 配 、 调 
度 、 配 置 、 部 署 等 管理 工作 。 例 如 : 部 署 不 同 版 本 的 应 用 到 不 同 的 环境 
中 ; 或 者 监控 和 分 析 应 用 (日 志 记 录 、 监 控 、 告 警 ) 等 。 一 些 常 用 的 
Label 示 例如 下 。 


。 版 本 标签 : “release”: “stable”, “release”: “canary”... 
。 环境 标 

签 : “environment”: “dev”, “environment”: 
。 架构 标 


签 : “tier”: “frontend”, “tier”: “backend”, “tier”: “middleware” 
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qa”, “environment”: 


e 分 区 标签 : “partition”: “customerA”, “partition”: “customerB”... 


。 质量 管控 标签 : “track”: “daily”, “track”: “weekly” 


Label 相 当 于 我 们 熟悉 的 “标签 ”"， 给 col 资源 对 象 定义 一 个 Label， 
束 相 当 于 给 它 打 了 一 个 标签 ， 随 后 可 以 通过 Label ”Selector( 标 签 选择 





ax) 查询 和 筛选 拥有 某 些 Label 的 资源 对 象 ，Kubernetes 通 过 这 种 方式 实 
现 了 类 似 SQL 的 简单 又 通用 的 对 象 查 询 机 制 。 


Label Selector 可 以 被 类 比 为 SQL 语句 中 的 where 碍 询 条 件 ， 例 如 ， 
name=redis-slave 这 个 Label Selector 作 用 于 Pod 时 ， 可 以 被 类 比 为 
select*from pod where pod’s name=‘redis-slave’ 这 样 的 语句 。 当 前 有 两 种 
Label ”Selector 的 表达 式 : 基于 等 式 的 (Equality-based〉 和 基于 集合 的 

(Set-based) ， 前 者 采用 “等 式 类 ”的 表达 式 匹 配 标签 ,下面 是 一 些 具 体 
的 例子 。 





e name=redis-slave: 匹配 所 有 具有 标签 name=redis-slave 的 资源 对 象 。 
e env! =production: 匹配 所 有 不 具有 标签 env=production 的 资源 对 
象 ， 比 如 env=test 束 是 满足 此 条 件 的 标签 之 一 











而 后 者 则 使 用 集合 操作 的 表达 式 匹配 标签 ， 下 面 是 一 些 具体 的 例 
子 。 


e name in (redis-master, redis-slave) : 匹配 所 有 具有 标签 
name=redis-master 或 者 name=redis-slave 的 资源 对 象 。 
e name notin (php-frontend) : 匹配 所 有 不 具有 标签 name=php- 


frontend 的 资源 对 象 。 


可 以 通过 多 个 Label Selector 表 达 式 的 组 合 实现 复杂 的 条 件 选择 ， 多 
个 表达 式 之 间 用 “，?” 进 行 分 隅 即 可 ， 几 个 条 件 之 间 是 “AND2” 的 关系 ， 即 
同时 满足 多 个 和 条件， 比如 下 面 的 例子 : 





name=redis-slave, env!=production 


name notin (php-frontend), env!=production 


Label Selector 在 Kubernetes 中 的 重要 使 用 场景 有 以 下 几 处 。 


e kube-controller 进 程 通 过 资源 对 象 RC 上 定义 的 Label Selector% ffi 
要 监控 的 Pod 副 本 的 数量 ， 从 而 实现 Pod 副 本 的 数量 始终 符合 预期 设 
定 的 全 上 自动 控制 流程 。 

e kube-proxy 进 程 通过 Service 的 Label Selector 来 选择 对 应 的 Pod， 自 动 
建立 起 每 个 Service 到 对 应 Pod 的 请 求 转发 路 由 表 ， 从 而 实现 Service 
的 智能 负载 均衡 机 制 。 

。 通过 对 某 些 Node 定 义 特 定 的 Label， 并 且 在 Pod 定 义 文件 中 使 用 
NodeSelector 这 种 标签 调度 策略 ，kube-scheduler 进 程 可 以 实现 
Pods [A] Val PE” A PTE o 








在 前 面 的 留言 板 例子 中 ， 我 们 只 使 用 了 一 个 name=XXX 的 Label 
Selector。 让 我 们 看 一 个 更 复杂 的 例子 。 假 设 为 Pod 定 义 了 3 个 Label: 
release、env 和 和 role， 不 同 的 Pod 定 义 了 不 同 的 Label 值 ， 如 图 1.9 所 示 ， 如 
果 我 们 设置 了 “role=frontend” 的 LabelSelector， 则 会 选取 到 Node 1 和 
Node2 上 的 Pod。 


而 设置 “release=beta” 的 LabelSelector， 则 会 选取 到 Node 2 和 Node3 上 
的 Pod， 如 图 1.10 所 示 。 


Selector: 
role=frontend 


-上 
release: beta 
env: testing 
role: frontend 


Node 2 


release: alpha 
env: development 
role: frontend 


Node 1 

















Labels: 
release: beta 
env: production 
role: backend 


Node 3 








图 1.9 Label Selector 的 作用 范围 1 














Labels: cs Labels: 
release: alpha i release: beta 
env: development env: testing 
role: frontend y role: frontend 
Node 1 / 


y Selector: 
release=beta 


release: beta 
env: production 
role: backend 





Node 3 





图 1.10 Label Selector 的 作用 范围 2 


总 结 : 使 用 Label 可 以 给 对 象 创建 多 组 标签 ，Label 和 LabelSelector 共 
同 构 成 了 Kubernetes 系 统 中 最 核心 的 应 用 模型 ， 使 得 被 管理 对 象 能 够 被 
精细 地 分 组 管理 ， 同 时 实现 了 整个 集群 的 高 可 用 性 。 


1.4.5 Replication Controller (RC) 


之 前 已 经 对 Replication Controller 〈 以 后 简称 RC) 的 定义 和 作用 做 
了 一 些 说 明 ， 本 节 对 RC 的 概念 进行 深入 描述 。 


RC 是 Kubernetes 系 统 中 的 核心 概念 之 一 ， 简 单 来 说 ， 它 其 实 是 定义 
了 一 个 期 望 的 场景 ， 即 声明 某 种 Pod 的 副本 数量 在 任意 时 刻 都 符合 某 个 
预期 值 ， 所 以 RC 的 定义 包括 如 下 几 个 部 分 。 


e Pod 期 竺 的 副本 数 (replicas) 。 
e 用 于 沛 选 日 标 Pod 的 Label Selector. 
e 当 Pod 的 副本 数量 小 于 预期 数量 的 时 候 ， 用 于 创建 新 Pod 的 Pod 模 板 


(template) 。 


下 面 是 一 个 完整 的 RC 定 义 的 例子 ， 即 确保 拥有 tier=frontend 标 签 的 
这 个 Pod (运行 Tomcat 容 器 〉 在 整个 Kubernetes 集 群 中 始终 只 有 一 个 副 
Aa 


apiVersion: v1 
kind: ReplicationController 
metadata: 
name: frontend 
spec: 
replicas: 1 


selector: 


tier: frontend 
template: 
metadata: 

labels: 
app: app-demo 
tier: frontend 

spec: 

containers: 

- name: tomcat-demo 
image: tomcat 
imagePullPolicy: IfNotPresent 
env: 

- name: GET_HOSTS_FROM 
value: dns 
ports: 


- containerPort: 80 
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上 的 Controller Manager 组 件 就 得 到 通知 ， 定 期 巡 检 系统 中 当前 存活 的 目 
标 Pod， 并 确保 目标 Pod 实 例 的 数量 刚好 等 于 此 RC 的 期 望 值 ， 如 果 有 过 
多 的 Pod 副 本 在 运行 ， 系 统 就 会 停 摊 一 些 Pod， 人 否则 系统 就 会 再 自动 创建 
一 些 Pod。 可 以 说 ， 通 过 RC，Kubernetes 实 现 了 用 户 应 用 集群 的 高 可 用 
性 ， 并 且 大 大 减少 了 系统 管理 员 在 传统 IT 环境 中 需要 完成 的 许多 手工 运 
维 工作 (如 主机 监控 脚本 、 应 用 监控 脚本 、 故 障 恢 复 脚 本 等 〉。 





下 面 我 们 以 3 个 Node 节 点 的 集群 为 例 ， 说 明 Kubernetes 如 何 通过 RC 
来 实现 Pod 副 本 数量 自动 控制 的 机 制 。 假 如 我 们 的 RC 里 定义 redis-slave 





这 个 Pod 需 要 保持 3 个 副本 ， 系 统 将 可 能 在 其 中 的 两 个 Node 上 创建 Pod。 
图 1.11 描 述 了 在 两 个 Node 上 创建 redis-slave Pod 的 情形 。 
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图 1.11 在 两 个 Node 上 创建 redis-slave Pod 


假设 Node 2 上 的 Pod 2 意外 终止 根据 RC 定 义 的 replicas 数 量 2， 
Kubernetes 将 会 目 动 创建 并 启动 一 个 新 的 Pod， 以 保证 整个 集群 中 始终 有 
两 个 redis-slave Pod 在 运行 。 


如 图 1.12 所 示 ， 系 统 可 能 选择 Node 3 或 者 Node 1 来 创建 一 个 新 的 
Pod. 
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Pod 1 Pod 3 
Node 1 Node 2 Node 3 
或 
Pod 1 Pod 3 
Node 1 Node 2 Node 3 


图 1.12 根据 RC 定义 创建 新 的 Pod 











此 外 ， 在 运行 时 ， 我 们 可 以 通过 修改 RC 的 副本 数量 ， 来 实现 Pod 的 
动态 缩放 (Scaling) 功能 ， 这 可 以 通过 执行 kubectl ”scale 命 令 来 一 键 完 
成 : 


$ kubectl scale rc redis-slave --replicas=3 


scaled 


Scaling 的 执行 结果 如 图 1.13 所 示 。 
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Pod 1 Pod 2 Pod 3 
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图 1.13 Scaling M447 44 


需要 注意 的 是 ， 删 除 RC 并 不 会 影响 通过 该 RC 已 创建 好 的 Pod。 为 
了 删除 所 有 Pod， 可 以 设置 replicas 的 值 为 0， 然 后 更 新 该 RC。 另 外 ， 
kubectl 提 供 了 stop 和 delete 命 令 来 一 次 性 删除 RC 和 RC 控制 的 全 部 Pod。 


当 我 们 的 应 用 升级 时 ， 通 常会 通过 Build 一 个 新 的 Docker 镜 像 ， 并 用 
新 的 镜像 版 本 来 答 代 旧 的 版本 的 方式 达到 目的 。 在 系统 升级 的 过 程 中 ， 
我 们 和 希望 是 平滑 的 方式 ， 比 如 当前 系统 中 10 个 对 应 的 旧版 本 的 Pod， 最 
佳 的 方式 是 旧版 本 的 Pod 每 次 停止 一 个 ， 同 时 创建 一 个 新 版 本 的 Pod， 在 
整个 升级 过 程 中 ， 此 消 役 长 ， 而 运行 中 的 Pod 数 量 始终 是 10 个 ， 几 分 钟 
以 后 ， 当 所 有 的 Pod 都 已 经 是 新 版 本 的 时 候 ， 升 级 过 程 完 成 。 通 过 RC 的 


机 制 ，Kubernetes 很 容易 就 实现 了 这 种 高 级 实用 的 特性 ， 被 称 为 “滚动 升 
级 ”(Rolling Update) ， 有 具体 的 操作 方法 详 见 第 4 章 。 


由 于 Replication Controller 与 Kubernetes 代 码 中 的 模块 Replication 
Controller 同 名 ， 同 时 这 个 词 也 无 法 准确 表达 它 的 本 意 ， 所 以 在 
Kubernetes 1.2 的 时 候 ， 它 就 升级 成 了 另外 一 个 新 的 概念 
Set， 官 方 解 释 为 “下 一 代 的 RC”， 它 与 RC 当前 存在 的 唯一 区 别 是 : 
Replica Sets 支 持 基 于 集合 的 Label selector (Set-based selector) ， 而 RC 只 
支持 基于 等 式 的 Label Selector (equality-based selector) ， 这 使 得 Replica 
Set 的 功能 更 强 ， 下 面 是 等 价 于 之 前 RC 例子 的 Replica Set 的 定义 (省 去 了 
Pod 模 板 部 分 的 内 容 〉: 











Replica 








apiVersion: extensions/vibeta1 
kind: ReplicaSet 
metadata: 
name: frontend 
spec: 
selector: 
matchLabels: 
tier: frontend 
matchExpressions: 
- {key: tier, operator: In, values: [frontend] } 


template: 


kubectl 命 令 行 工 具 适 用 于 RC 的 绝 大 部 分 命令 都 同样 适用 于 Replica 
Set。 此 外 ， 当 前 我 们 很 少 单独 使 用 Replica Set， 它 主要 个 Deployment 这 


个 更 高 层 的 资源 对 象 所 使 用 ， 从 而 形成 一 整套 Pod 创 建 、 删 除 、 更 新 的 
编排 机 制 。 当 我 们 使 用 Deployment 时 ， 无 须 关 心 它 是 如 何 创建 和 维护 
Replica Set 的 ， 这 一 切 都 是 自动 发 生 的 。 


Replica Set 与 Deployment 这 两 个 重要 资源 对 象 逐 步 蔡 换 了 之 前 的 RC 
的 作用 ， 是 Kubernetes 1.3 里 Pod 自 动 扩容 〈 伸 缩 ) 这 个 告警 功能 实现 的 
基础 ， 也 将 继续 在 Kubernetes 未 来 的 版 本 中 发 挥 重 要 的 作用 。 


最 后 我 们 总 结 一 下 关于 RC (Replica Set) 的 一 些 特性 与 作用 。 


在 大 多 数 情 况 下 ， 我 们 通过 定义 一 个 RC 实现 Pod 的 创建 过 程 及 副本 
数量 的 自动 控制 。 

RC 里 包括 完整 的 Pod 定 义 模 板 。 

RC 通过 Label Selector 机 制 实 现 对 Pod 副 本 的 自动 控制 。 

通过 改变 RC 里 的 Pod 副 本 数量 ， 可 以 实现 Pod 的 扩容 或 缩 容 功能 。 

通过 改变 RC 里 Pod 模 板 中 的 镜像 版 本 ， 可 以 实现 Pod 的 滚动 升级 功 


型 


e 
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1.4.6 Deployment 





Deployment 是 Kubernetes 1.2 引 入 的 新 概念 ， 引 入 的 目的 是 为 了 更 好 
地 解决 Pod 的 编排 问题 。 为 此 ，Deployment 在 内 部 使 用 PREA Set 来 实 
现 目 的 ， 无 论 从 Deployment 的 作用 与 目的 、 它 的 YAM 定 义 ， 还 是 从 它 
的 具体 命令 行 操作 来 看 ， 我 们 都 可 以 把 它 看 作 RC 的 一 次 升级 ， 两 者 的 
相似 度 超过 909%6。 








Deployment 相 对 于 RC 的 一 个 最 大 升级 是 我 们 可 以 随时 知道 当前 
Pod“ 部 署 ? 的 进度 。 实 际 上 由 于 一 个 Pod 的 创建 、 调 度 、 绑 定 节 点 及 在 目 
标 Node 上 启动 对 应 的 容器 这 一 完整 过 程 需 要 一 定 的 时 间 ， 所 以 我 们 期 待 
系统 局 动 N 个 Pod 副 本 的 目标 状态 ， 实 际 上 是 一 个 连续 变化 的 “部 普 过 
程 ” 导 致 的 最 终 状 态 。 








Deployment 的 典型 使 用 场景 有 以 下 几 个 。 





。 创建 一 个 Deployment 对 象 来 生成 对 应 的 Replica Set 并 完成 Pod 副 本 的 
创建 过 程 。 

。 检查 Deployment 的 状态 来 看 部 署 动作 是 否 完 成 〈Pod 副 本 的 数量 是 
侍 达 到 预期 的 值 〉。 

。 更 新 Deployment 以 创建 新 的 Pod《〈 比 如 镜像 升级 ) 。 

。 如 果 当 前 Deployment 不 稳定 ， 则 回 深 到 一 个 早先 的 Deployment 版 
AS 

e 挂 起 或 者 恢复 一 个 Deployment。 





Deployment 的 定义 与 Replica Set 的 定义 很 类 似 ， 除 了 API 声 明 与 Kind 


类 型 等 有 所 区 别 : 


apiVersion: extensions/vibetal apiVersion: 

kind: Deployment kind: ReplicaS 

metadata: metadata: 
name: nginx-deployment name: nginx- 


下 面 我 们 通过 运行 一 些 例子 来 一 起 直观 地 感受 这 个 新 概念 。 首 移 创 
建 一 个 名 为 tomcat-deployment.yaml 的 Deployment 描 述 文件 ， 内 容 如 下 : 


apiVersion: extensions/vibeta1 
kind: Deployment 
metadata: 
name: frontend 
spec: 
replicas: 1 
selector: 
matchLabels: 
tier: frontend 
matchExpressions: 
- {key: tier, operator: In, values: [frontend] } 
template: 
metadata: 
labels: 
app: app-demo 
tier: frontend 


spec: 


containers: 

- name: tomcat-demo 
image: tomcat 
imagePullPolicy: IfNotPresent 
ports: 


- containerPort: 8080 


运行 下 述 命 令 创 建 Deployment: 


# kubectl create -f tomcat-deployment.yaml 


deployment "tomcat-deploy" created 


运行 下 述 命令 查看 Deployment 的 信息 : 


# kubectl get deployments 
NAME DESTRED CURRENT UP-TO-DATE AVAILABLE l 


tomcat-deploy 1 1 1 1 


对 上 述 输出 中 涉及 的 数量 解释 如 下 。 


DESIRED: Pod 副 本 数量 的 期 望 值 ， 即 Deployment 里 定义 的 
Replica. 

CURRENT: 当前 Replica 的 值 ， 实 际 上 是 Deployment 所 创建 的 
Replica Set 里 的 Replica 值 ， 这 个 值 不 断 增 加 ， 直 到 达到 DESIRED 为 
iE, 表明 整 个 部 署 过 程 完成 。 

UP-TO-DATE: 最 新 版 本 的 Pod 的 副本 数量 ， 用 于 指示 在 滚动 升级 
的 过 程 中 ， 有 多 少 个 Pod 副 本 已 经 成 功 升级 。 

AVAILABLE: 当前 集群 中 可 用 的 Pod 副 本 数量 ， 即 集群 中 当前 存 








活 的 Pod 数 量 。 


运行 下 述 命令 得 看 对 应 的 Replica Set， 我 们 看 到 它 的 命名 跟 
Deployment 的 名 字 有 关系 : 


#kubectl get rs 
NAME DESIRED CURRENT AGE 
tomcat -deploy-1640611518 1 1 1m 


运行 下 述 命令 查看 创建 的 Pod， 我 们 发 现 Pod 的 命名 以 Deployment 对 
应 的 Replica Set 的 名 字 为 前 级 ， 这 种 命名 很 清晰 地 表明 了 一 个 Replica Set 
创建 了 哪些 Pod， 对 于 Pod 演 动 升级 这 种 复杂 的 过 程 来 说 ， 很 容易 排查 错 
误 : 


# kubectl get pods 
NAME READY STATUS RES’ 


tomcat -deploy-1640611518-zhrsc 1/1 Running 0 


运行 kubectl describe deployments， 可 以 清楚 地 看 到 Deployment 控 制 
的 Pod 的 水 平 扩展 过 程 ， 此 命令 的 输出 比较 多 ， 这 里 不 再 更 述 。 


1.4.7 Horizontal Pod Autoscaler (HPA ) 


在 前 两 节 提 到 过 ， 通 过 手工 执行 kubectl = scale 命令 ， 我 们 可 以 实现 
Pod 扩 容 或 缩 容 。 如 果 仅 仅 到 此 为 止 ， 显 然 不 符合 谷歌 对 Kubernetes 的 定 
位 目标 自动 化 、 重 能 化 。 在 谷歌 看 来 ， 分 布 式 系统 要 能 够 根据 当前 
负载 的 变化 情况 自动 触发 水 平 扩展 或 缩 容 的 行为 ， 因 为 这 一 过 程 可 能 是 
频繁 发 生 的 、 不 可 预料 的 ， 所 以 手动 控制 的 方式 是 不 现实 的 。 











因此 ，Kubernetes 的 1.0 版 本 实现 后 ， 这 帮 大 牛 们 就 已 经 在 默默 研究 
Pod 智 能 扩容 的 特性 了 ， 并 在 Kubernetes1.1 的 版 本 中 首次 发 布 这 一 重量 
级 新 特性 一 一 Horizontal Pod Autoscaling。 随 后 的 1.2 版 本 中 HPA 被 升级 
为 稳定 版 本 CapiVersion: autoscaling/v1) ， 但 同时 仍然 保留 旧版 本 
(apiVersion: extensions/vlbetal) ， 官 方 的 计划 是 在 1.3 版 本 里 先 移 除 
旧版 本 ， 并 且 会 在 1.4 版 本 里 彻底 移 除 旧版 本 的 支持。 











Horizontal Pod Autoscaling 人 简称 HPA， 意 思 是 Pod 横 向 自动 扩容 ， 与 
之 六 的 RC、Deployment 一 样 ， 也 属于 一 种 Kubernetes 资 源 对 象 。 通 过 氨 
踊 分 析 RC 控 制 的 所 有 目标 Pod 的 负载 变化 情况 ， 来 确定 是 否 需 要 针对 性 
地 调整 目标 Pod 的 副本 数 ， 这 是 HPA 的 实现 原理 。 当 前 ，HPA 可 以 有 以 
下 两 种 方式 作为 Pod 负 载 的 度量 指标 。 








e CPUUtilizationPercentage。 
。 应 用 程序 自 定义 的 度量 指标 ， 比 如 服务 在 每 秒 内 的 相应 的 请 求 数 
CTPS 或 QPS) 。 





CPUUtilizationPercentage 是 一 个 算术 平均 值 ， 即 目标 Pod 所 有 副本 自 


身 的 CPU 利用 率 的 平均 值 。 一 个 Pod 上 自身 的 CPU 利用 率 是 该 Pod 当 前 CPU 
的 使 用 量 除 以 它 的 Pod Request 的 值 ， 比 如 我 们 定义 一 个 Pod 的 Pod 
Reduest 为 0.4， 而 当前 Pod 的 CPU 使 用 量 为 0.2， 则 和 它 的 CPU 使 用 率 为 
50%， 如 此 一 来 ， 我 们 就 可 以 就 算出 来 一 个 RC 控 制 的 所 有 Pod 副 本 的 
CPU 利用 率 的 算术 平均 值 了 。 如 果 某 一 时 刻 CPUUtilizationPercentage 的 
值 超过 80%， 则 意味 着 当前 的 Pod 副 本 数 很 可 能 不 足以 支撑 接 下 来 更 多 
的 请 求 ， 需 要 进行 动态 扩容 ， 而 当 请 求 高 峰 时 上 段 过 去 后 ，Pod 的 CPU 利 
用 率 又 会 降下 来 ， 此 时 对 应 的 Pod 副 本 数 应 该 自动 减少 到 一 个 合理 的 水 
Fe 























CPUUtilizationPercentage 计 算 过 程 中 使 用 到 的 Pod 的 CPU 使 用 量 通 常 
是 1 分 钟 内 的 平均 值 ， 目 前 通过 查询 Heapster 扩 展 组 件 来 得 到 这 个 值 ， 所 
以 需要 安装 部 着 Heapster， 这 样 一 来 便 增 加 了 系统 的 复杂 上 度 和 实施 HPA 
特性 的 复杂 度 ， 因 此 ， 未 来 的 计划 是 Kubernetes 自 喘 实 现 一 个 基础 性 能 
数据 采集 模块 ， 从 而 更 好 地 支持 HPA 和 其 他 需要 用 到 基础 性 能 数据 的 功 
能 模块 。 此 外 ， 我 们 也 看 到 ， 如 果 目 标 Pod 没 有 定义 Pod Request 的 值 ， 
则 无 法 使 用 CPUUrtilizationPercentage 来 实现 Pod 横 同上 自动 扩容 的 能 力 。 除 
了 使 用 CPUUtilizationPercentage，Kubermnetes 从 1.2 版 本 开始 ， 和 尝试 支持 
应 用 程序 自 定义 的 度量 指标 ， 目 前 仍然 为 实验 特性 ， 不 建议 在 生产 环境 
中 使 用 。 








下 面 是 HPA 定 义 的 一 个 具体 例子 : 


apiVersion: autoscaling/v1i 
kind: HorizontalPodAutoscaler 
metadata: 


name: php-apache 


namespace: default 
spec: 
maxReplicas: 10 
minReplicas: 1 
scaleTargetRef: 
kind: Deployment 
name: php-apache 


targetCPUUtilizationPercentage: 90 


根据 上 面 的 定义 ， 我 们 可 以 知道 这 个 HPA 控 制 的 目标 对 象 为 一 个 名 
叫 php-apache 的 Deployment 里 的 Pod 副 本 ， 当 这 些 Pod 副 本 的 
CPUUtilizationPercentage 的 值 超过 90% 时 会 触发 目 动 动态 扩容 行为 ， 扩 
容 或 缩 容 时 必须 满足 的 一 个 约束 条 件 是 Pod 的 副本 数 要 介 于 1 与 10 之 间 。 








除了 可 以 通过 直接 定义 yaml 文 件 并 且 调用 kubectrl create 的 命令 来 创 
建 一 个 HPA 资 源 对 象 的 方式 ， 我 们 还 能 通过 下 面 的 简单 命令 行 直 接 创建 
等 价 的 HPA 对 象 : 


# kubectl autoscale deployment php-apache --cpu-percent=! 


第 2 章 将 会 给 出 一 个 完整 的 HPA 例 子 来 说 明 其 用 法 和 功能 。 


1.4.8 Service (Ak) 


1. 概 述 


Service 也 是 Kubernetes 里 的 最 核心 的 资源 对 象 之 一 ，Kubernetes 里 的 
每 个 Service 其 实 就 是 我 们 经 弟 提 起 的 微服 务 架 构 中 的 一 个 “微服 务 ”， 之 
前 我 们 所 说 的 Pod、RC 等 资源 对 象 其 实 都 是 为 这 节 上 所 说 的 “服务 “一 一 
Kubernetes ”Service 做 “ 嫁 衣 ”的 。 图 1.14 显 示 了 Pod、RC 与 Service 的 逻辑 
关系 。 
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图 1.14 Pod、RC 与 Service 的 关系 


从 图 1.14 中 我 们 看 到 ，Kubernetes 的 Service 定 义 了 一 个 服务 的 访问 
入 口 地 址 ， 前 端的 应 用 《〈Pod) 通过 这 个 入 口 地 址 访问 其 背后 的 一 组 由 
Pod 副 本 组 成 的 集群 实例 ，Service 与 其 后 端 Pod 副 本 集群 之 间 则 是 通过 
Label Selector 来 实现 “无 颖 对 接 ” 的 。 而 RC 的 作用 实际 上 是 保证 Service 的 
服务 能 力 和 服务 质量 始终 处 于 预期 的 标准 。 





通过 分 析 、 识 别 并 建 模 系 统 中 的 所 有 服务 为 微服 务 


Kubernetes 


Service， 最 终 我 们 的 系统 由 多 个 提供 不 同业 务 能 力 而 又 彼此 独立 的 微服 
务 单元 所 组 成 ， 服 务 之 间 通 过 TCP/IP 进 行 通信 ， 从 而 形成 了 我 们 强大 而 
又 灵活 的 弹性 网 格 ， 拥 有 了 强大 的 分 布 式 能 力 、 弹 性 扩展 能 力 、 容 错 能 
力 ， 与 此 同时 ， 我 们 的 程序 架构 也 变 得 简单 和 直观 许多 ， 如 图 1.15 所 
ZN o 





既然 每 个 Pod 都 会 被 分 配 一 个 单独 的 了 P 地 址 ， 而 且 每 个 Pod 都 提供 了 
一 个 独立 的 Endpoint (Pod IP+ContainerPort) 以 被 客户 端 访问 ， 现 在 多 
个 Pod 副 本 组 成 了 一 个 集群 来 提供 服务 ， 那 么 客户 端 如 何 来 访问 它们 
We? 一 般 的 做 法 是 部 署 一 个 负载 均衡 器 (软件 或 硬件 ) ， 为 这 组 Pod 开 
启 一 个 对 外 的 服务 端口 如 8000 端 口 ， 并 且 将 这 些 Pod 的 Endpoint 列 表 加 
入 8000 端 口 的 转发 列表 中 ， 客 户 端 就 可 以 通过 负载 均衡 器 的 对 外 JP 地址 
+ 服务 端口 来 访问 此 服务 ， 而 客户 端的 请 求 最 后 会 被 转发 到 哪个 Pod， 则 
由 负载 均衡 器 的 算法 所 决定 。 
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图 1.15 ”Kubernetes 所 提供 的 微服 务 网 格 架 构 


Kubernetes 也 遵循 了 上 述 和 常规 做 法 ， 运 行 在 每 个 Node 上 的 kube- 


proxy 进 程 其 实 就 是 一 个 智能 的 软件 负载 均衡 右 ， 它 负 贡 把 对 Service 的 
请 求 转 发 到 后 端的 某 个 Pod 实 例 上 ， 并 在 内 部 实现 服务 的 负载 均衡 与 会 
话 保持 机 制 。 但 Kubernetes 发 明了 一 种 很 巧妙 又 影响 深远 的 设计 : 
Service 不 是 共用 一 个 负载 均衡 器 的 IP 地 址 ， 而 是 每 个 Service 分 配 了 一 个 
全 局 唯一 的 虚拟 IP 地 址 ， 这 个 虚拟 IP 被 称 为 Cluster IP。 这 样 一 来 ， 每 个 
服务 束 变 成 了 具备 唯一 JP 地址 的 “通信 节点 ”， 服 务 调用 就 变 成 了 最 基础 
的 TCP 网 络 通 信 问 题 。 





我 们 知道 ，Pod 的 Endpoint 地 址 会 随 者 Pod 的 销毁 和 重新 创建 而 发 生 
改变 ， 因 为 新 Pod 的 IP 地 址 与 之 前 旧 Pod 的 不 同 。 而 Service 一 旦 创建 ， 
Kubernetes 就 会 自动 为 它 分 配 一 个 可 用 的 Cluster IP， 而 且 在 Service 的 整 
个 生命 周期 内 ， 它 的 Cluster IP 不 会 发 生 改 变 。 于 是 ， 服 务必 现 这 个 环 手 
的 问题 在 Kubernetes 的 架构 里 也 得 以 轻松 解决 ， 只 要 用 Service 的 Name 与 
Service 的 Cluster IP 地 址 做 一 个 DNS 域名 映射 即 可 完美 解决 问题 。 现 在 想 
想 ， 这 真是 一 个 很 棒 的 设计 。 








说 了 这 么 久 ， 下 面 我 们 动手 创建 一 个 Service， 来 加 深 对 它 的 理解 。 
首先 我 们 创建 一 个 名 为 tomcat-service.yaml 的 定义 文件 ， 内 容 如 下 : 


apiVersion: v1 
kind: Service 
metadata: 
name: tomcat-service 
spec: 
ports: 
- port: 8080 


selector: 


tier: frontend 


上 述 内 容 定 义 了 一 个 名 为 *tomcat-service” 的 Service， 它 的 服务 端口 
为 8080， 拥 有 “tier=frontend” 这 个 Label 的 所 有 Pod 实 例 都 属于 它 ， 运 行 下 
面 的 命令 进行 创建 : 


#kubectl create -f tomcat-server.yaml 


service "tomcat-service" created 


注意 到 我 们 之 前 在 tomcat-deployment.yaml 里 定义 的 Tomcat 的 Pod 刚 
好 拥有 这 个 标签 ， 所 以 我 们 刚才 创建 的 tomcat-service 已 经 对 应 到 了 一 个 
Pod 实 例 ， 运 行 下 面 的 命令 可 以 查看 tomcat-service 的 Endpoint 列 表 ， 其 中 
172.17.1.3 是 Pod 的 卫 地 址 ， 端 口 8080 是 Container 暴 露 的 端口 : 


# kubectl get endpoints 


NAME ENDPOINTS AGE 
kubernetes 192.168.18.131:6443 15d 
tomcat-service 172.17.1.3:8080 1m 


你 可 能 有 疑问 : “说 好 的 Service 的 Cluster IPE? 怎么 没有 看 到 ?” ”我 
们 运行 下 面 的 命令 即 可 看 到 tomct-service 被 分 配 的 Cluster IP 及 更 多 的 信 


J&S 


# kubectl get svc tomcat-service -0 yaml 
apiVersion: v1 
kind: Service 


metadata: 


creationTimestamp: 2016-07-21T17:05:52Z 
name: tomcat-service 
namespace: default 
resourceVersion: "23964" 
selfLink: /api/vi/namespaces/default/services/tomcat-si 
uid: 61987d3c-4f65-11e6 -a9d8 -000c29ed42c1 
spec: 
ClusterIP: 169.169.65.227 
ports: 
- port: 8080 
protocol: TCP 
targetPort: 8080 
selector: 
tier: frontend 
sessionAffinity: None 
type: ClusterIP 
status: 


loadBalancer: {} 





在 spec.ports 的 定义 中 ，targetPort 属 性 用 来 确定 提供 该 服务 的 容器 所 
Jig (EXPOSE) 的 病 口 号 ， 即 具体 业务 进程 在 容器 内 的 targetPort 上 提 
供 TCP/IP 接 入 ; 而 port 属 性 则 定义 了 Service 的 虚 端 口 。 前 面 我 们 定义 
Tomcat 服 务 的 时 候 ， 没 有 指定 targetPort， 则 默认 targetPort 与 port 相 同 。 





接 下 来 ， 我 们 来 看 看 Service 的 多 端口 问题 。 


很 多 服务 都 存在 多 个 端口 的 问题 ， 通 常 一 个 端口 提供 业务 服务 ， 忆 


外 一 个 端口 提供 管理 服务 ， 比 如 Mycat、Codis 等 第 见 中 间 件 。 
Kubernetes Service 文 持 多 个 Endpoint， 在 存在 多 个 Endpoint 的 情况 下 ， 要 
求 每 个 Endpoint 定 义 一 个 名 字 来 区 分 。 下 面 是 Tomcat 多 端口 的 Service 定 
义 样 例 : 


apiVersion: vi 
kind: Service 
metadata: 

name: tomcat-service 
spec: 

ports: 

- port: 8080 

name: service-port 

- port: 8005 

name: shutdown-port 

selector: 


tier: frontend 


多 端口 为 什么 需要 给 每 个 端口 命名 呢 ? ea Ae Kubernetes Hy IR 
发 现 机 制 了 ， 我 们 接 下 来 进行 讲解 。 


2.Kubernetes 的 服务 发 现 机 制 


任何 分 布 式 系统 都 会 涉及 “服务 发 现 ” 这 个 基础 问题 ， 大 部 分 分 布 式 
系统 通过 提供 特定 的 API 接 口 来 实现 服务 发 现 的 功能 ， 但 这 样 做 会 导致 
平台 的 侵入 性 比较 强 ， 也 增加 了 开发 测试 的 困难 。Kubernetes 则 采用 了 
直观 朴素 的 思路 去 解决 这 个 棘手 的 问题 。 


首先 ， 每 个 Kubernetes 中 的 Service 都 有 一 个 唯一 的 Cluster IP 以 及 唯 
一 的 名 字 ， 而 名 字 是 由 开发 者 自己 定义 的 ， 部 署 的 时 候 也 没 必要 改变 ， 
所 以 完全 可 以 固定 在 配置 中 。 接 下 来 的 问题 就 是 如 何 通 过 Service 的 名 字 
找到 对 应 的 Cluster IP? 


最 早 的 时 候 Kubernetes 采 用 了 Linux 环 境 变 量 的 方式 解决 这 个 问题 ， 
即 每 个 Service 生 成 一 些 对 应 的 Linux 环 境 变量 ENV) ， 并 在 每 个 Pod 的 
容器 在 启动 时 ， 自 动 注 入 这 些 环境 变量 ， 以 以 下 是 tomcat-service 产 生 的 
环境 变量 条 目 


TOMCAT_SERVICE_SERVICE_HOST=169.169.41.218 
TOMCAT_SERVICE_SERVICE_PORT_SERVICE_PORT=8080 
TOMCAT_SERVICE_SERVICE_PORT_SHUTDOWN_PORT=8005 
TOMCAT_SERVICE_SERVICE_PORT=8080 
TOMCAT_SERVICE_PORT_8005_TCP_PORT=8005 





TOMCAT_SERVICE_PORT=tcp://169.169.41.218: 8080 
TOMCAT_SERVICE_PORT_8080_TCP_ADDR=169 .169.41.218 





TOMCAT_SERVICE_PORT_8080_TCP=tcp://169.169.41.218: 8080 





TOMCAT_SERVICE_PORT_8080_TCP_PROTO=tcp 





TOMCAT_SERVICE_PORT_8080_TCP_PORT=8080 





TOMCAT_SERVICE_PORT_8005_TCP=tcp://169.169.41.218:8005 





TOMCAT_SERVICE_PORT_8005_TCP_ADDR=169.169.41.218 





TOMCAT_SERVICE_PORT_8005_TCP_PROTO=tcp 








上 述 环境 变量 中 ， 比 较 重 要 的 是 前 3 条 环境 变量 ， 我 们 可 以 看 到 ， 
每 个 Service 的 耳 地 址 及 端口 都 是 有 标准 的 命名 规范 的 ， 遵 循 这 个 命名 规 
范 ， 就 可 以 通过 代码 访问 系统 环境 变量 的 方式 得 到 所 需 的 信息 ， 实 现 服 


务 调用 。 





考虑 到 环境 变量 的 方式 获取 Service 的 卫 与 端口 的 方式 仍然 不 太 方 
便 ， 不 够 直观 ， 后 来 Kubernetes 通 过 Add-On 增 值 包 的 方式 引入 了 DNS 系 
统 ， 把 服务 名 作为 DNS 域名 ， 这 样 一 来 ， 程 序 就 可 以 直接 使 用 服务 名 来 
建立 通信 连接 了 。 目 前 Kubernetes 上 的 大 部 分 应 用 都 已 经 采用 了 DNS 这 
些 新 兴 的 服务 发 现 机 制 ， 后 面 的 章节 中 我 们 会 讲述 如 何 部 署 这 套 DNS 系 
统 。 








3. 外 部 系统 访问 Service 的 问题 


为 了 更 加 深入 地 理解 和 掌握 Kubernetes， 我 们 需要 弄 明 白 Kubernetes 
里 的 “三 种 IP” 这 个 关键 问题 ， 这 三 种 IP 分 别 如 下 。 


e Node IP: Node 节 点 的 IP 地 址 。 
e Pod IP: Pod 的 IP 地 址 。 
e Cluster IP: Service 的 IP 地 址 。 


首先 ，Node IP 是 Kubernetes 集 群 中 每 个 节点 的 物理 网 卡 的 IP 地 址 ， 
这 是 一 个 真实 存在 的 物理 网 络 ， 所 有 属于 这 个 网 络 的 服务 器 之 间 都 能 通 
过 这 个 网 络 直接 通信 ， 不 管 它们 中 是 否 有 部 分 节点 不 属于 这 个 
Kubernetes 人 集群。 这 也 表明 了 Kubernetes 集 群 之 外 的 节点 访问 Kubernetes 
集群 之 内 的 某 个 节点 或 者 TCP/IP 服 务 的 时 候 ， 必 须要 通过 Node ”IP 进行 
通信 。 





其 次 ，Pod IP 是 每 个 Pod 的 IP 地 址 ， 它 是 Docker Engine 根 据 docker0 
网 桥 的 IP 地 址 段 进行 分 配 的 ， 通 常 是 一 个 虚拟 的 二 层 网 络 ， 前 面 我 们 说 
过 ，Kubernetes 要 求 位 于 不 同 Node 上 的 Pod 能 够 彼此 直接 通信 ， 所 以 


Kubernetes 里 一 个 Pod 里 的 容 咒 访问 另外 一 个 Pod 里 的 容器 ， 融 是 通过 
Pod IP 所 在 的 虚拟 二 层 网 络 进 行 通 信 的 ， 而 真实 的 TCP/IP 流 量 则 是 通过 
Node IP 所 在 的 物理 网 卡 流出 的 。 





最 后 ， 我 们 说 说 Service 的 Cluster IP， 它 也 是 一 个 虚拟 的 IP， 但 更 像 


是 一 个 “伪造 ”的 JP 网络 ， 原 因 有 以 下 几 点 。 


Cluster 了 下 仅仅 作用 于 Kubernetes Service 这 个 对 象 ， 并 由 Kubernetes 
管理 和 分 配 IP 地 址 (来 源 于 Cluster IP 地 址 池 〉。 

Cluster IP 无 法 被 Ping， 因 为 没有 一 个 “实体 网 络 对 象 ” 来 响应 。 
Cluster IP 只 能 结合 Service Port 组 成 一 个 具体 的 通信 端口 ， 单 独 的 
Cluster IP 不 具备 TCP/IP 通 信 的 基础 ， 并 且 它 们 属于 Kubernetes 集 群 
这 样 一 个 封闭 的 空间 ， 集 群 之 外 的 节点 如 果 要 访问 这 个 通信 端口 ， 
则 需要 做 一 些 额外 的 工作 。 

在 Kubernetes 集 群 之 内 ，Node IP}. Pod IP 网 与 Cluster IP 网 之 间 的 
通信 ， 采 用 的 是 Kubernetes 上 自己 设计 的 一 种 编程 方式 的 特殊 的 路 由 
规则 ， 与 我 们 所 熟知 的 卫 路 由 有 很 大 的 不 同 。 


根据 上 面 的 分 析 和 总 结 ， 我 们 基本 明白 了 : Service 的 Cluster IP 属 于 


Kubernetes 集 群 内 部 的 地 址 ， 无 法 在 集群 外 部 直接 使 用 这 个 地 址 。 那 么 
FERIT: 实际 上 我 们 开发 的 业务 系统 中 肯定 多 少 有 一 部 分 服务 是 要 提 
供给 Kubernetes 集 群 外 部 的 应 用 或 者 用 户 来 使 用 的 ， 典 型 的 例子 就 是 
Web 端 的 服务 模块 ， 比 如 上 面 的 tomcat-service， 那 么 用 户 怎么 访问 它 ? 











采用 NodePort 是 解决 上 述 问 题 的 最 直接 、 最 有 效 、 最 各 用 的 做 法 。 


具体 做 法 如 下 ， 以 tomcat-service 为 例 ， 我 们 在 Service 的 定义 里 做 如 下 扩 
展 即 可 〈 黑 体 字 部 分 ) : 


apiVersion: v1 

kind: Service 
metadata: 

name: tomcat-service 
spec: 

type: NodePort 

ports: 

- port: 8080 
nodePort: 31002 

selector: 


tier: frontend 


其 中 ，nodePort: 31002 这 个 属性 表明 我 们 手动 指定 tomcat-service 的 
NodePort 为 31002， 人 否则 Kubernetes 会 上 自动 分 配 一 个 可 用 的 端口 。 接 下 
来 ， 我 们 在 浏览 器 里 访问 http://<nodePort IP>: 31002/， 就 可 以 看 到 
Tomat 的 欢迎 界面 了 ， 如 图 1.16 所 示 。 





192.168.18.131:31002 
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图 1.16 ”通过 NodePort 访 问 Service 





NodePort 的 实现 方式 是 在 Kubernetes 集 群 里 的 每 个 Node 上 为 需要 外 
部 访问 的 Service 开 启 一 个 对 应 的 TCP 监 听 端 口 ， 外 部 系统 只 要 用 任意 一 
个 Node 的 了 P 地 址 + 有 具体 的 NodePort 端 口号 即 可 访问 此 服务 ， 在 任意 Node 
上 运行 netstat 命 令 ， 我 们 束 可 以 看 到 有 NodePort 冰 口 被 监听 : 


# netstat -tlp|grep 31002 


tcp6 0 © [::]:31002 ee De LISTI 


但 NodePort 还 没有 完全 解决 外 部 访问 Service 的 所 有 问题 ， 比 如 负载 
均衡 问题 ， 假 如 我 们 的 集群 中 有 10 个 Node， 则 此 时 最 好 有 一 个 负载 均衡 
器 ， 外 部 的 请 求 只 需 访问 此 负载 均衡 器 的 JP 地址 ， 由 负载 均衡 器 负责 转 
发 流量 到 后 面 某 个 Node 的 NodePort 上 。 如 图 1.17 所 示 。 
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图 1.17 NodePort 与 Load balancer 


图 1.17 中 的 Load balancer 组 件 独 立 于 Kubernetes 集 群 之 外 ， 通 常 是 一 
个 硬件 的 负载 均衡 器 ， 或 者 是 以 软件 方式 实现 的 ， 例 如 HAProxy 或 者 
Nginx。 对 于 每 个 Service， 我 们 通常 需要 配置 一 个 对 应 的 Load balancer 实 
例 来 转发 流量 到 后 端的 Node 上 ， 这 的 确 增加 了 工作 量 及 出 错 的 概率 。 于 
是 Kubernetes 提 供 了 自动 化 的 解决 方案 ， 如 果 我 们 的 集群 运行 在 谷歌 的 
GCE 公 有 云 上 ， 那 么 只 要 我 们 把 Service 的 type=NodePort 改 为 
type=LoadBalancer， 此 时 Kubernetes 会 自动 创建 一 个 对 应 的 Load balancer 
实例 并 返回 它 的 IP 地 址 供 外 部 客户 端 使 用 。 其 他 公有 云 提 供 商 只 要 实现 
了 文 持 此 特性 的 驱动 ， 则 也 可 以 达到 上 述 目 的 。 此 外 ， 裸 机 上 的 类 似 机 
fill (Bare Metal Service Load Balancers) 也 正在 被 开发 。 


1.4.9 Volume (存储 卷 ) 


Volume 是 Pod 中 能 够 被 多 个 容器 访问 的 共享 目录 。Kubernetes 的 
Volume 概 念 、 用 途 和 目的 与 Docker 的 Volume 比 较 类 似 ， 但 两 者 不 能 等 
价 。 首 先 ，Kubernetes 中 的 Volume 定 义 在 Pod 上 ， 然 后 被 一 个 Pod 里 的 多 
个 容器 挂 载 到 具体 的 文件 目录 下 ; 其次，Kubernetes 中 的 Volume 与 Pod 
的 生命 周期 相同 ， 但 与 容器 的 生命 周期 不 相关 ， 当 容器 终止 或 者 重 局 
时 ，Volume 中 的 数据 也 不 会 丢失 。 最 后 ，Kubernetes 文 持 多 种 类 型 的 
Volume， 例 如 GlusterFS、Ceph 等 先进 的 分 布 式 文 件 系统 。 





Volume 的 使 用 也 比较 简单 ， 在 大 多 数 情况 下 ， 我 们 移 在 Pod 上 声明 
一 个 Volume， 然 后 在 容器 里 引用 该 Volume 并 Mount 到 容器 里 的 某 个 目录 
上 。 举 例 来 说 ， 我 们 要 给 之 前 的 Tomcat ”Pod 增 加 一 个 名 字 为 dataVol 的 
Volume， 并 且 Mount 到 容器 的 /mydata-data 目 录 上 ， 则 只 要 对 Pod 的 定义 
文件 做 如 下 修正 即 可 (注意 黑体 字 部 分 〉: 


template: 
metadata: 
labels: 
app: app-demo 
tier: frontend 
spec: 
volumes: 
- name: datavol 


emptyDir: {} 


containers: 
- name: tomcat-demo 
image: tomcat 
volumeMounts: 
- mountPath: /mydata-data 
name: datavol 


imagePullPolicy: IfNotPresent 


除了 可 以 让 一 个 Pod 里 的 多 个 容器 共享 文件 、 让 容器 的 数据 写 到 宿 
主机 的 磁盘 上 或 者 写 文 件 到 网 络 存 储 中 ，Kubernetes 的 Volume 还 扩展 出 
了 一 种 非常 有 实用 价值 的 功能 ， 即 容器 配置 文件 集中 化 定义 与 管理 ， 这 
是 通过 ConfigMap 这 个 新 的 资源 对 象 来 实现 的 ， 后 面 我 们 会 详细 说 明 。 


Kubernetes 提 供 了 非常 丰富 的 Volume 类 型 ， 下 面 逐 一 进行 说 明 。 


1.emptyDir 


一 个 emptyDir Volume 是 在 Pod 分 配 到 Node 时 创建 的 。 从 它 的 名 称 束 
可 以 看 出 ， 它 的 初始 内 容 为 空 ， 并 且 无 须 指 定 宿主 机 上 对 应 的 目录 文 
件 ， 因 为 这 是 Kubernetes 上 自动 分 配 的 一 个 目录 ， 当 Pod 从 Node 上 移 除 
时 ，emptyDir 中 的 数据 也 会 被 永久 删除 。emptyDir 的 一 些 用 途 如 下 。 





-> 


-> 


临时 空间 ， 例 如 用 于 某 些 应 用 程序 运行 时 所 需 的 临时 目录 ， 且 无 须 
永久 保留 。 

长 时 间 任 务 的 中 间 过 程 CheckPoint 的 临时 保存 目录 。 

一 个 容器 需要 从 男 一 个 容器 中 获取 数据 的 目录 (多 容器 共享 日 

K) o 








目前 ， 用 户 无 法 控制 emptyDir 使 用 的 介质 种 类 。 如 果 kubelet 的 配置 
是 使 用 硬盘 ， 那 么 所 有 emptyDir 都 将 创建 在 该 硬盘 上 。Pod 在 将 来 可 以 
设置 emptyDir 是 位 于 硬盘、 固态 人 硬盘 上 还 是 基于 内 存 的 tmpfs 上 ， 上 面 的 
例子 便 采 用 了 emptyDir 类 的 Volume。 





2.hostPath 





hostPath 为 在 Pod 上 挂 载 宿主 机 上 的 文件 或 目录 ， 它 通常 可 以 用 于 以 
PULA. 





。 容器 应 用 程序 生成 的 日 志文 件 需要 永久 保存 时 ， 可 以 使 用 宿主 机 的 
高 速 文件 系统 进行 存储 。 

需要 访问 宿主 机 上 Docker 引 擎 内 部 数据 结构 的 容器 应 用 时 ， 可 以 通 
过 定义 hostPath 为 宿主 机 /var/lib/docker 目 录 ， 使 容器 内 部 应 用 可 以 
直接 访问 Docker 的 文件 系统 。 











在 使 用 这 种 类 型 的 Volume 时 ， 需 要 注意 以 下 几 点 。 





在 不 同 的 Node 上 具有 相同 配置 的 Pod 可 能 会 因为 宿主 机 上 的 目录 和 
文件 不 同 而 导致 对 Volume 上 目录 和 文件 的 访问 结果 不 一 致 。 

e 如 果 使 用 了 资源 配额 管理 ， 则 Kubernetes 无 法 将 hostPath 在 宿主 机 上 
使 用 的 资源 纳入 管理 。 


在 下 面 的 例子 中 使 用 宿主 机 的 /data 目 录 定 义 了 一 个 hostPath 类 型 的 


Volume: 


volumes: 


- name: "persistent-storage" 


hostPath: 


path: "/data" 


3.gcePersistentDisk 


使 用 这 种 类 型 的 Volume 表 示 使 用 谷歌 公有 云 提供 的 永久 磁盘 
(Persistent Disk, PD) 存放 Volume 的 数据 ， 它 与 EmptyDir 不 同 ，PD 上 
的 内 容 会 被 永久 保存 ， 当 Pod 被 删除 时 ，PD 只 是 被 凶 载 (Unmount) , 
但 不 会 被 删除 。 需 要 注意 的 是 ， 你 需要 先 创建 一 个 永久 磁盘 (PD) ， 
才能 使 用 gcePersistentDisk。 


使 用 gcePersistentDisk 有 以 下 一 些 限制 条 件 。 





e Node (运行 kubelet 的 节点 ) 需要 是 GCE 虚 拟 机 。 
。 这 些 虚 拟 机 需要 与 PD 存在 于 相同 的 GCE 项 目 和 Zone 中 。 


通过 gcloud 命 令 即 可 创建 一 个 PD: 


gcloud compute disks create --size=500GB --zone=us-centr 


定义 gcePersistentDisk 类 型 的 Volume 的 示例 如 下 : 


volumes: 
- name: test-volume 
# This GCE PD must already exist. 
gcePersistentDisk: 
pdName: my-data-disk 


fsType: ext4 


4.awsElasticBlockStore 


与 GCE 类 似 ， 该 类 型 的 Volume 使 用 亚马逊 公有 云 提 供 的 EBS 
Volume 存 储 数 据 ， 需 要 先 创 建 一 个 EBSVolume 才 能 使 用 


awsElasticBlockStore. 


使 用 awsElasticBlockStore 的 一 些 限 制 条 件 如 下 。 





e Node (运行 kubelet 的 节点 ) 需要 是 AWS EC2 实 例 。 

e 这 些 AWS ”EC2 实 例 需 要 与 EBS volume 存在 于 相同 的 region 和 
availability-zone 中 。 

。 EBS 只 文 持 单 个 EC2 实 例 mount 一 个 volume。 


通过 aws ec2create-volume 命 令 可 以 创建 一 个 EBS volume: 


aws ec2 create-volume --availability-zone eu-west-1a --s. 


定义 awsElasticBlockStore 类 型 的 Volume 的 示例 如 下 : 


volumes: 
- Name: test-volume 
# This AWS EBS volume must already exist. 
awsElasticBlockStore: 
volumeID: aws://<availability-zone>/<volume -id> 


fsType: ext4 


5.NFS 


使 用 NFS 网 络 文件 系统 提供 的 共享 目录 存储 数据 时 ， 我 们 需要 在 系 
统 中 部 署 一 个 NFS Server。 和 定义 NFS 类 型 的 Volume 的 示例 如 下 : 


volumes: 
- name: nfs 
nfs: 
# 改 为 你 的 NFS 服 务 器 地 址 
server: nfs-server.localhost 


path: "/" 


6. 其 他 类 型 的 Volume 


e iscsi: 使 用 iSCSI 存储 设备 上 的 目录 挂 载 到 Pod 中 。 

flocker: 使 用 Flocker 来 管理 存储 卷 。 

e glusterfs: 使 用 开源 GlusterFS 网 络 文件 系统 的 目录 挂 载 到 Pod 中 。 

e rbd: 使 用 Linux 块 设备 共享 存储 (Rados Block Device) 挂 载 到 Pod 
中 。 

e gitRepo: 通过 挂 载 一 个 空 目 录 ， 并 从 GIT 库 clone 一 个 git repository 
以 供 Pod 使 用 。 

e secret: 一 个 secret volume 用 于 为 Pod 提 供 加 密 的 信息 ， 你 可 以 将 定 
义 在 Kubernetes 中 的 secret 直 接 挂 载 为 文件 让 Pod 访 问 。secret volume 
是 通过 tmfs (内 存 文件 系统 ) 实现 的 ， 所 以 这 种 类 型 的 volume 总 是 
不 会 持久 化 的 。 


1.4.10 Persistent Volume 


之 前 我 们 提 到 的 Volume 是 定义 在 Pod 上 的 ， 属 于 “计算 资源 ”的 一 部 
分 ， 而 实际 上 , “网 络 存储 ?是 相对 独立 于 “计算 资源 ”而 存在 的 一 种 实体 
资源 。 比 如 在 使 用 虚 机 的 情况 下 ， 我 们 通常 会 先 定 义 一 个 网 络 存 储 ， 然 
后 从 中 划 出 一 个 “网 盘 ? 并 挂 接 到 虚 机 上 。Persistent Volume (fi #KPV) 
和 与 之 相关 联 的 Persistent Volume Claim 〈 简 称 PVC) 也 起 到 了 类 似 的 作 
用 。 











PV 可 以 理解 成 Kubernetes 集 群 中 的 某 个 网 络 存 储 中 对 应 的 一 块 存 
储 ， 它 与 Volume 很 类 似 ， 但 有 以 下 区 别 。 





。 PV 只 能 是 网 络 存 储 ， 不 属于 任何 Node， 但 可 以 在 每 个 Node 上 访 
问 。 

e PV 并 不 是 定义 在 Pod 上 的 ， 而 是 独立 于 Pod 之 外 定义 。 

PV 目 前 只 有 几 种 类 型 : GCE Persistent Disks, NFS, RBD, 

iSCSCI、AWS ElasticBlockStore、GlusterFS 等 。 


下 面 给 出 了 NFS 类 型 PV 的 一 个 yaml 定 义 文 件 ， 声 明了 需要 5Gi 的 存 
储 空间 : 


apivVersion: vi 
kind: PersistentVolume 
metadata: 


name: pv0003 


spec: 

Capacity: 

storage: 5Gi 
accessModes: 

- ReadWriteOnce 
nfs: 

path: /somepath 

server: 172.17.0.2 


比较 重要 的 是 PV 的 accessModes 属 性 ， 目 前 有 以 下 类 型 。 


e ReadWriteOnce: 读 写 权限 、 并 且 只 能 被 单个 Node 挂 载 。 
e ReadOnlyMany: 只 读 权 限 、 人 允许 被 多 个 Node 挂 载 。 
e ReadWriteMany: 读 写 权限 、 人 允许 被 多 个 Node 挂 载 。 


如 果菜 个 Pod 想 申请 某 种 条 件 的 PV， 则 首先 需要 定义 一 个 
PersistentVolumeClaim (PVC) 对 象 : 


kind: PersistentVolumeClaim 
apiVersion: v1 
metadata: 
name: myclaim 
spec: 
accessModes: 
- ReadWriteOnce 
resources: 
requests: 


storage: 8Gi 


et 


然后 ， 在 Pod 的 Volume 定 义 中 引用 上 述 PVC 即 可 : 


volumes: 
- name: mypd 
persistentVolumeClaim: 


ClaimName: myclaim 





最 后 ， 我 们 说 说 PV 的 状态 ，PV 是 有 状态 的 对 象 ， 它 有 以 下 几 种 状 


Available: 空 闪 状态 。 

Bound: 已 经 绑 定 到 某 个 PVC 上 。 

Released: 对 应 的 PVC 已 经 删除 ， 但 资源 还 没有 被 集群 收回 。 
Failed: PV 自动 回收 失败 。 


1.4.11 Namespace 〈 命 名 空间 ) 


Namespace (命名 空间 ) 是 Kubernetes 系 统 中 的 另 一 个 非常 重要 的 概 
念 ，Namespace 在 很 多 情况 下 用 于 实现 多 租户 的 资源 隔离 。Namespace 
通过 将 集群 内 部 的 资源 对 象 “ 分 配 ” 到 不 同 的 Namespace 中 ， 形 成 逻辑 上 
分 组 的 不 同 项 目 、 小 组 或 用 户 组 ， 便 于 不 同 的 分 组 在 共享 使 用 整个 集群 
的 资源 的 同时 还 能 被 分 别管 理 。 








Kubernetes 集 群 在 启动 后 ， 会 创建 一 个 名 为 “default* 的 Namespace,， 
通过 kubectl 可 以 查看 到 : 


$ kubectl get namespaces 
NAME LABELS STATUS 


default <none> Active 


接 下 来 ， 如 果 不 特别 指明 Namespace， 则 用 户 创建 的 Pod、RC、 
Service 都 将 被 系统 创建 到 这 个 默认 的 名 为 default 的 Namespace 中 。 


Namespace 的 定义 很 简单 。 如 下 所 示 的 yaml 定 义 了 名 为 development 


的 Namespace。 


apiVersion: v1 
kind: Namespace 
metadata: 


name: development 


一 旦 创建 了 Namespace， 我 们 在 创建 资源 对 象 时 就 可 以 指定 这 个 资 
源 对 象 属 于 哪个 Namespace。 比 如 在 下 面 的 例子 中 ， 我 们 定义 了 一 个 名 
为 busybox 的 Pod， 放 入 development 这 个 Namespace 里 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: busybox 
namespace: development 
spec: 
containers: 
- image: busybox 
command: 
- sleep 
- "3600" 


name: busybox 





此 时 ， 使 用 kubectl get 命 令 查 看 将 无 法 显示 : 


$ kubectl get pods 
NAME READY STATUS RESTARTS AGE 


这 是 因为 如 果 不 加 参数 ， 则 kubectl get 命 令 将 仅 显 示 属 于 “default” 命 
名 空间 的 资源 对 象 。 


可 以 在 kubectl 命 令 中 加 入 --namespace 参 数 来 查看 某 个 命名 空间 中 的 
WR: 


# kubectl get pods --namespace=development 
NAME READY STATUS RESTARTS AGE 


busybox 1/1 Running 0 1m 





当 我 们 给 每 个 租户 创建 一 个 Namespace 来 实现 多 租户 的 资源 隔离 
时 ， 还 能 结合 Kubernetes 的 资源 配额 管理 ， 限 定 不 同 租户 能 占用 的 资 
源 ， 例 如 CPU 使 用 量 、 内 存 使 用 量 等 。 关 于 资源 配额 管理 的 问题 ， 在 后 
面 的 章节 中 会 详细 介绍 。 


1.4.12 Annotation (注解 ) 


Annotation 与 Label 类 似 ， 也 使 用 key/value 键 值 对 的 形式 进行 定义 。 
不 同 的 是 Label 具 有 严格 的 命名 规则 ， 它 定义 的 是 Kubernetes 对 象 的 元 数 
据 〈Metadata) ， 并 且 用 于 Label Selector。 而 Annotation 则 是 用 户 任 意 定 
义 的 “附加 ”信息 ， 以 便于 外 部 工具 进行 查找 ， 很 多 时 候 ，Kubernetes 的 
模块 自身 会 通过 Annotation 的 方式 标记 资源 对 象 的 一 些 特 殊 信 息 。 








通常 来 说 ， 用 Annotation 来 记录 的 信息 如 下 。 


e build 信息、release 信 息 、Docker 镜 像 信 息 等 ， 例 如 时 间 惟 、release 
id 号 、PR 号 、 镜 像 hash 值 、docker registry 地 址 等 。 

。 日 志 库 、 监 控 库 、 分 析 库 等 资源 库 的 地 址 信息 。 

程序 调试 工具 信息 ， 例 如 工具 名 称 、 版 本 号 等 。 

团队 的 联系 信息 ， 例 如 电话 号 码 、 负 责 人 名 称 、 网 址 等 。 


Ate 2a 


上 述 这 些 组 件 是 Kubernetes 系 统 的 核心 组 件 ， 它 们 共同 构成 了 
Kubernetes 系 统 的 框架 和 计算 模型 。 通 过 对 它们 进行 灵活 组 合 ， 用 户 就 
可 以 快速 、 方 便 地 对 容器 集群 进行 配置 、 创 建 和 管理 。 除 了 本 章 所 介绍 
的 核心 组 件 ， 在 Kubernetes 系 统 中 还 有 许多 辅助 配置 的 资源 对 象 ， 例 如 
LimitRange、ResourceQuota。 男 外 ， 一 些 系 统 内 部 使 用 的 对 象 Binding、 
Event 等 请 参考 Kubernetes 的 API 文 档 。 


在 第 2 曹 中， 我们 将 开始 深入 实践 并 全 面 掌握 Kubernetes 的 各 种 使 用 
技巧 。 


第 2 瘟 KubemetesSc ests pa 


本 章 将 从 Kubermnetes 的 系统 安装 开始 ， 逐 步 介 绍 Kubernetes 的 服务 相 
关 配 置 、 命 令 行 工 具 kubectl 的 使 用 详解 ， 然 后 通过 大 量 案例 实践 对 
Kubernetes 最 核心 的 容器 和 微服 务 架构 的 概念 和 用 法 进行 详细 说 明 。 





2.1 Kubernetes 安 装 与 配置 


2.1.1 安装 Kubernetes 


Kubernetes 系 统 由 一 组 可 执行 程序 组 成 ， 用 户 可 以 通过 GitHub 上 的 
Kubernetes 项 目 页 下 载 编译 好 的 二 进 制 包 ， 或 者 下 载 源 代码 并 编译 后 进 
行 安 装 。 





安装 Kubernetes 对 软件 和 硬件 的 系统 要 求 如 表 2.1 所 示 。 
表 2.1 安装 Kubernetes 对 软件 和 硬件 的 系统 要 求 


软 硬 件 最 低 配 置 推荐 配置 

CPU 和 内 存 | Master: 至 少 1 core 和 2GB 内 存 Master: 2 core 和 4GB 内 存 

Node: 至 少 1 core 和 2GB 内 存 Node: 由 于 要 运行 Docker, 所 以 应 根 
据 需 要 运行 的 容器 数量 进行 调整 
Linux 操作 | 基于 x86_64 架构 的 各 种 Linux 发 行 版 本 ， 包 括 Red Hat Linux, | Red Hat Linux 7 

系统 CentOS, Fedora, Ubuntu 4}, Kemel 版 本 要 求 在 3.10 及 以 上 。 CentOS 7 

也 可 以 在 谷歌 的 GCE(Google Compute Engine ) 或 者 Amazon 的 AWS 


(Amazon Web Service) 云 平 台 上 进行 安装 














最 低 配 置 推荐 配置 
1.9 版 本 及 以 上 1.12 版 本 
下 载 和 安装 说 明 见 https://www.docker.com 
2.0 版 本 及 以 上 3.0 版 本 

















下 载 和 安装 说 明 见 hnttps://github.com/coreos/etcd/releases 


最 简单 的 安装 方法 是 使 用 yum install kubernetes 命 令 完 成 Kubernetes 
集群 的 安装 ， 但 仍 需 修改 各 组 件 的 启动 参数 ， 才 能 完成 Kubernetes 集 群 
的 配置 。 


本 章 以 二 进 制 文件 和 手工 配置 局 动 参数 的 形式 进行 安装 ， 对 每 个 组 
件 的 配置 进行 详细 说 明 。 





从 Kubernetes 官 网 下 载 编译 好 的 二 进 制 包 ， 如 图 2.1 所 示 ， 下 载 地 址 
为 https:/github.com/kubernetes/kubernetes/releases。 本 书 基于 Kubernetes 
1.3 版 本 进行 说 明 。 


v1.3.0 


J david-mcmahon released this on 2 Jul - 179 commits to release-1.3 since this release 


See kubernetes-announce@ and CHANGELOG for details. 


Downloads 


P kubernetes.tar.gz 


图 2.1 GitHub 上 Kubernetes 的 下 载 页 面 


在 压缩 包 kubernetes.tar.gz 内 包含 了 Kubernetes 的 服务 程序 文件 、 文 
档 和 示例 。 


解压 缩 后 ，server 子 目录 中 的 kubernetes-server-linux-amd64.tar.gz 文 
件 包 含 了 Kubernetes 需 要 运行 的 全 部 服务 程序 文件 。 服 务 程序 文件 列表 
如 表 2.2 所 示 。 


表 2.2 ”服务 程序 文件 列表 


说 了 明 
hyperkube 总 控 程 序 ， 用 于 运行 其 他 Kubernetes 程序 














kube-apiserver apiserver 主 程序 





kube-apiserver.docker tag apiserver docker 镜像 的 tag 





kube-apiserver.tar apiserver docker 镜像 文件 





kube-controller-manager controller-manager 主 程序 





kube-controller-manager.docker_tag controller-manager docker 镜像 的 tag 





kube-controller-manager.tar controller-manager docker 镜像 文件 


kubectl 客户 端 命令 行 工具 











kubelet kubelet 主 程序 











kube-proxy proxy 主 程序 








kube-scheduler scheduler 主 程序 





kube-scheduler.docker_tag scheduler docker 镜像 的 tag 


kube-scheduler.tar scheduler docker 镜像 文件 











Kubernetes Master 节 点 安装 部 署 etcd、kube-apiserver、kube- 
controller-manager、kube-scheduler 服 务 进程 。 我 们 使 用 kubectl 作 为 客户 
端 与 Master 进 行 交 互 操作 ， 在 工作 Node 上 仅 需 部 署 kubelet 和 kube-proxy 
服务 进程 。Kubernetes 还 提供 了 一 个 “all-in-one” 的 hyperkube 程 序 来 完成 
对 以 上 服务 程序 的 局 动 。 


2.1.2 配置 和 局 动 Kubernetes 服 务 


Kubernetes 的 服务 都 可 以 通过 直接 运行 二 进 制 文件 加 上 局 动 参数 完 
成 。 为 了 便于 管理 ， 篆 见 的 做 法 是 将 Kubernetes 服 务 程序 配置 为 Linux 的 
系统 开机 上 自动 启动 的 服务 。 


本 节 以 CentOS Linux 7 为 例 ， 使 用 Systemd 系 统 完成 Kubernetes 服 务 
的 配置 。 其 他 Linux 发 行 版 的 服务 配置 请 参考 相关 的 系统 管理 手册 。 





需要 注意 的 是 ，CentOS Linux 7 默认 启动 了 firewalld 一 一 防火 墙 服 

， [而 Kubernetes 的 Master 与 工作 Node 之 间 会 有 大 量 的 网 络 通信 ， 安 全 

iE EBEN PB A 口号 ， 有 具体 要 配置 的 

端口 号 详 见 2.1.6 节 中 各 服务 监听 的 端口 号 说 明 。 在 一 个 安全 的 内 部 网 络 
环境 中 可 以 关闭 防火 墙 服 务 : 








# systemctl disable firewalld 


# systemctl stop firewalld 


将 Kubernetes 的 可 执行 文件 复制 到 /usr/bin (如果 复制 到 其 他 目录 ， 
则 将 systemd 服 务 文件 中 的 文件 路 径 修 改正 确 妈 可， ， 然 后 对 服务 进行 
配置 。 








在 下 面 的 服务 启动 参数 说 明 中 主要 介绍 最 重要 的 局 动 参数 ， 每 个 服 
务 的 局 动 参数 还 有 很 多 ， 详 见 2.1.6 节 的 完整 说 明 。 有 兴趣 的 读者 可 以 举 
试 修 改 它 们 ， 以 观 穴 服 务 运行 的 不 同 效 果 。 


1.Master 上 的 etcd、kube-apiserver、kube-controller-manager、kube- 


scheduler 服 务 


1) etcd 服 务 





etcd 服 务 作为 Kubernetes 和 集群 的 主 数据 库 ， 在 安装 Kubernetes 各 服务 
之 前 需要 首先 安装 和 启动 。 


从 GitHub 官 网 下 载 etcd 发 布 的 二 进 制 文件 ， 将 etcd 和 etcdctl 文 件 复制 
到 /usr/bin 目 录 。 


设置 systemd 服 务 文 件 /usr/lib/systemd/system/etcd.service: 


[Unit] 
Description=Etcd Server 


After=network.target 


[Service] 

Type=simple 
WorkingDirectory=/var/lib/etcd/ 
EnvironmentFile=-/etc/etcd/etcd.conf 


ExecStart=/usr/bin/etcd 


[Install] 


WantedBy=multi-user. target 





=Æ 


其 中 WorkingDirectory (/var/lib/etcd/) 表示 etcd 数 据 保存 的 目录 ， 需 
要 在 局 动 etcd 服 务 之 前 进行 创建 。 


配置 文件 /etc/etcd/etcd.conf 通 常 不 需要 特别 的 参数 设置 (详细 的 参 
数 配 置 内 容 参 见 官 方 文档 ) ，etcd 默 认 将 监听 在 http:/127.0.0.1: 2379 地 
址 供 客户 端 连接 。 


配置 完成 后 ， 通 过 systemctl ”start 命 令 启 动 etcd 服 务 。 同 时 ， 使 用 
systemctl enable 命 令 将 服务 加 入 开机 启动 列表 中 : 


# systemctl daemon-reload 
# systemctl enable etcd.service 


# systemctl start etcd.service 


通过 执行 etcdctl cluster-health， 可 以 验证 etcd 是 否 正 确 局 动 : 


# etcdctl cluster-health 
member ce2a822cea30bfca is healthy: got healthy result f 


cluster is healthy 
2) kube-apiserver 服 务 


将 kube-apiserver 的 可 执行 文件 复制 到 /usr/bin 目 录 。 


编辑 systemd 服 务 文件 /usr/lib/systemd/system/kube-apiserver.service,， 
内 容 如 下 : 


[Unit] 
Description=Kubernetes API Server 


Documentation=https://github.com/GoogleCloudPlatform/kub: 


After=etcd.service 


Wants=etcd.service 


[Service] 
EnvironmentFile=/etc/kubernetes/apiserver 
ExecStart=/usr/bin/kube-apiserver $KUBE_API_ARGS 
Restart=on-failure 

Type=notify 

LimitNOFILE=65536 


[Install] 


WantedBy=multi-user. target 


配置 文件 /etc/kubernetes/apiserver 的 内 容 包 括 了 kube-apiserver 的 全 部 
局 动 参数 ， 主 要 的 配置 参数 在 变量 KUBE_API_ARGS 中 指定 。 


# cat /etc/kubernetes/apiserver 


KUBE_API_ARGS="--etcd_servers=http://127.0.0.1:2379 --in 


对 局 动 参数 的 说 明 如 下 。 


e --etcd_servers: 指定 etcd 服 务 的 URL。 

e --insecure-bind-address: apiserver 绑 定 主机 的 非 安 全 IP 地 址 ， 设 置 
0.0.0.0 表 示 绑 定 所 有 IP 地 址 。 

e --insecure-port: apiserver 绑 定 主机 的 非 安 全 端口 号 ， 默 认为 8080。 

e --service-cluster-ip-range: Kubernetes 集 群 中 Service 的 虚拟 IP 地 址 段 
范围 ， 以 CIDR 格 式 表 示 ， 例 如 169.169.0.0/16， 该 了 范围 不 能 与 物 
理 机 的 真实 IP 段 有 重合 。 





--service-node-port-range: Kubernetes 集 群 中 Service 可 映射 的 物理 机 
端口 号 范围 ， 默 认为 30000 一 32767。 

--admission_control: Kubernetes 集 群 的 准 入 控制 设置 ， 各 控制 模块 
以 插件 的 形式 依次 生效 。 

--logtostderr: 设置 为 false 表 示 将 日 志 写 入 文件 ， 不 写 入 stderr。 
--log-dir: 日 志 目 录 。 

--V: 日 志 级 别 。 





3) kube-controller-manager 服 务 


kube-controller-manager 服 务 依赖 于 kube-apiserver 服 务 。 


# cat /usr/lib/systemd/system/kube-controller-manager.se 
[Unit] 

Description=Kubernetes Controller Manager 
Documentation=https://github.com/GoogleCloudPlatform/kubi 
After=kube-apiserver.service 


Requires=kube-apiserver.service 


[Service] 
EnvironmentFile=/etc/kubernetes/controller -manager 
ExecStart=/usr/bin/kube-controller-manager $KUBE_CONTROL 
Restart=on-failure 


LimitNOFILE=65536 


[Install] 


WantedBy=multi-user.target 


配置 文件 /etc/kubernetes/controller-manager 的 内 容 包 括 了 kube- 
controller-manager 的 全 部 启动 参数 ， 主 要 的 配置 参数 在 变量 
KUBE_CONTROLLER_MANAGER_ARGS 中 指定 。 


# cat /etc/kubernetes/controller-manager 


KUBE_CONTROLLER_MANAGER_ARGS="--master=http://192.168.18 


对 局 动 参数 的 说 明 如 下 。 


e --master: 指定 apiserver 的 URL 地 址 。 

e --logtostderr: 设置 为 false 表 示 将 日 志 写 入 文件 ， 不 写 入 stderr。 
e --log-dir: H&A. 

e -v: 日 志 级 别 。 





4) kube-scheduler 服 务 


kube-scheduler 服 务 也 依赖 于 kube-apiserver 服 务 。 


# cat /usr/lib/systemd/system/kube-controller-manager.se 
[Unit] 

Description=Kubernetes Controller Manager 
Documentation=https://github.com/GoogleCloudPlatform/kub 
After=kube-apiserver.service 


Requires=kube-apiserver.service 


[Service] 
EnvironmentFile=/etc/kubernetes/scheduler 


ExecStart=/usr/bin/kube-scheduler $KUBE_SCHEDULER_ARGS 


Restart=on-failure 


Limi tNOFILE=65536 


[Install] 


WantedBy=multi-user.target 


配置 文件 /etc/kubernetes/scheduler 的 内 容 包 括 了 kube-scheduler 的 全 
部 启动 参数 ， 主 要 的 配置 参数 在 变量 KUBE_SCHEDULER_ARGS 中 指 
FE o 
# cat /etc/kubernetes/scheduler 


KUBE_SCHEDULER_ARGS="- -master=http://192.168.18.3:8080 - 


对 局 动 参数 的 说 明 如 下 。 


e --master: 指定 apiserver 的 URL 地 址 。 

e --logtostderr: 设置 为 false 表 示 将 日 志 写 入 文件 ， 不 写 入 stderr。 
e --log-dir: 日 志 目 录 。 

。--V: 日 志 级 别 。 





配置 完成 后 ， 执 行 systemctl start 命 令 按 顺序 启动 这 3 个 服务 。 同 
时 ， 使 用 systemctl enable 命 令 将 服务 加 入 开机 启动 列表 中 。 


systemctl daemon-reload 
systemctl enable kube-apiserver.service 
systemctl start kube-apiserver.service 


systemctl enable kube-controller-manager 


+ + + + T+ 


systemctl start kube-controller -manager 


# systemctl enable kube-scheduler 


# systemctl start kube-scheduler 


通过 systemctl status<service_name> 来 验证 服务 的 启动 状 
态 ，“Tunning” 表 示 启 动 成 功 。 





到 此 ，Master 上 所 需 的 服务 就 全 部 启动 完成 了 。 


2.Node 上 的 kubelet、kube-proxy 服 务 


在 工作 Node 节 点 上 需要 预先 安装 好 Docker Daemon 并 且 正 名 局 动 。 
Docker 的 安装 详 见 http:/www.docker.com 的 说 明 。 


1) kubelet 服 务 


kubelet 服 务 依赖 于 Docker 服 务 。 


# cat /usr/lib/systemd/system/kubelet.service 

[Unit] 

Description=Kubernetes Kubelet Server 
Documentation=https://github.com/GoogleCloudPlatform/kub 
After=docker.service 


Requires=docker.service 


[Service ] 
WorkingDirectory=/var/lib/kubelet 
EnvironmentFile=/etc/kubernetes/kubelet 


ExecStart=/usr/bin/kubelet $KUBELET_ARGS 


Restart=on-failure 


[Install] 


WantedBy=multi-user.target 








其 中 WorkingDirectory 表 示 kubelet 保 存 数据 的 目录 ， 需 要 在 启动 


kubelet 服 务 之 前 进行 创建 。 


数 ， 


配置 文件 /etc/kubernetes/kubelet 的 内 容 包 括 了 kubelet 的 全 部 启动 参 
主要 的 配置 参数 在 变量 KUBELET_ARGS 中 指定 。 


# cat /etc/kubernetes/kubelet 


KUBELET_ARGS="--api-servers=http://192.168.18.3:8080 --h 


对 启动 参数 的 说 明 如 下 。 


--api-servers: 指定 apiserver 的 URL 地 址 ， 可 以 指定 多 个 。 
--hostname-override: 设置 本 Node 的 名 称 。 

--logtostderr: 设置 为 false 表 示 将 日 志 写 入 文件 ， 不 写 入 stderr。 
--log-dir: Hii AX. 

--V: 日 志 级 别 。 





2) kube-proxy 服 务 


kube-proxy 服 务 依赖 于 network 服 务 。 


[Unit ] 
Description=Kubernetes Kube-Proxy Server 


Documentation=https://github.com/GoogleCloudPlatform/kub 


After=network.target 


Requires=network.service 


[Service | 
EnvironmentFile=/etc/kubernetes/proxy 
ExecStart=/usr/bin/kube-proxy $KUBE_PROXY_ARGS 
Restart=on-failure 


Limi tNOFILE=65536 


[Install] 


WantedBy=multi-user. target 


配置 文件 /etc/kubernetes/proxy 的 内 容 包 括 了 kube-proxy 的 全 部 局 动 
参数 ， 主 要 的 配置 参数 在 变量 KUBE_PROXY_ARGS 中 指定 。 


# cat /etc/kubernetes/proxy 
KUBE_PROXY_ARGS="--master=http://192.168.18.3:8080 --log 


对 局 动 参数 的 说 明 如 下 。 


e --master: 指定 apiserver 的 URL 地 址 。 

e --logtostderr: 设置 为 false 表 示 将 日 志 写 入 文件 ， 不 写 入 stderr。 
e --log-dir: 日 志 目 录 。 

。--V: 日 志 级 别 。 





配置 完成 后 ， 通 过 systemct 启 动 kubelet 和 kube-proxy 服 务 : 


# systemctl daemon-reload 


systemctl enable kubelet.service 
systemctl start kubelet.service 


systemctl enable kube-proxy 


+ + + # 


systemctl start kube-proxy 


kubelet 默 认 采 用 向 Master 自 动 注册 本 Node 的 机 制 ， 在 Master 上 查看 
各 Node 的 状态 ， 状 态 为 Ready 表 示 Node 已 经 成 功 注 册 并 且 状 态 为 可 用 。 


# kubectl get nodes 
NAME STATUS AGE 
192.168.18.3 Ready 1m 


等 所有 Node 的 状态 都 为 Ready 之 后 ， 一 个 Kubernetes 集 群 就 启动 完 
成 了 。 接 下 来 就 可 以 创建 Pod、RC、Service 等 资源 对 象 来 部 署 Docker 容 
器 应 用 了 。 


2.1.3 Kubernetes 集 群 的 安全 设置 





1. 基 于 CA 签名 的 双 同 数字 证 书 认证 方式 


自 一 个 安全 的 内 网 环境 中 ，Kubemetes 的 各 个 组 件 与 Master 之 间 可 
以 通过 apiserver 的 非 安 全 端口 http://apiserver: 8080 进 行 访问 。 但 如 果 
apiserver 需 要 对 外 提供 服务 ， 或 者 集群 中 的 某 些 容器 也 需要 访问 
apiserver 以 获取 集群 中 的 某 些 信息 ， 则 更 安全 的 做 法 是 局 用 HTTPS 安 全 
机 制 。Kubernetes 提 供 了 基于 CA 签名 的 双 同 数字 证 书 认证 方式 和 简单 的 
基于 HTTP BASE 或 TOKEN 的 认证 方式 ， 其 中 CA 证 书 方式 的 安全 性 最 
高 。 本 节 先 介绍 以 CA 证 书 的 方式 配置 Kubernetes 集 群 ， 要 求 Master 上 的 
kube-apiserver、kube-controller-manager、kube-scheduler 进 程 及 各 Node 上 
的 kubelet、kube-proxy 进 程 进行 CA 签名 双 问 数字 证 书 安全 设置 。 











基于 CA 签名 的 双 回 数字 证 书 的 生成 过 程 如 下 。 
(1) 为 kube-apiserver 生 成 一 个 数字 证 书 ， 并 用 CA 证 书 进 行 签 名 。 


(2) 为 kube-apiserver 进 程 配置 证 书 相 关 的 局 动 参数 ， 包 括 CA 证 书 
(用 于 验证 客户 端 证 书 的 签名 真 伪 〉) 、 目 己 的 经 过 CA 签名 后 的 证 书 及 
FLH o 


(3) 为 每 个 访问 Kubernetes API Server 的 客户 端 〈 如 kube- 
controller-manager、kube-scheduler、kubelet、kube-proxy 及 调用 API 
Server 的 客户 端 程序 kubectl 等 ) 进程 生成 自己 的 数字 证 书 ， 也 都 用 CA 证 
书 进行 签名 ， 在 相关 程序 的 局 动 参数 里 增加 CA 证 书 、 上 自己 的 证 书 等 相 


1) 设置 kube-apiserver 的 CA 证 书 相 关 的 文件 和 启动 参数 


使 用 OpenSSL 工 具 在 Master 服 务 器 上 创建 CA 证 书 和 私 铀 相关 的 文 
件 : 


# openssl genrsa -out ca.key 2048 
# openssl req -x509 -new -nodes -key ca.key -subj "/CN=y 


# openssl genrsa -out server.key 2048 


注意 : 生成 ca.crt 时 ，-subj 参 数 中 “/CN” 的 值 通常 为 域名 。 


准备 master_ssl.cnf 文 件 ， 该 文件 用 于 x509v3 版 本 的 证 书 。 在 该 文件 
中 主要 需要 设置 Master 服 务 器 的 hostname (k8s-master) 、IP 地 址 
(192.168.18.3) ， 以 及 Kubernetes Master ”Service 的 虚拟 服务 名 称 
(kubernetes.default 等 和 该 虚拟 服务 的 ClusterIP 地 址 (169.169.0.1) 。 





master_ssl.cnf 文 件 的 示例 如 下 : 


[req] 

req_extensions = v3_req 

distinguished_name = req_distinguished_name 
[req_distinguished_name ] 

[ v3_req ] 

basicConstraints = CA:FALSE 

keyUsage = nonRepudiation, digitalSignature, keyEncipher! 


subjectAltName = @alt_names 


[alLt_names ] 

DNS.1 = kubernetes 

DNS.2 = kubernetes.default 

DNS.3 = kubernetes.default.svc 

DNS.4 = kubernetes.default.svc.cluster.local 


DNS.5 = k8s-master 


IP.1 = 169.169.0.1 


IP.2 = 192.168.18.3 


基于 master_ssl.cnf 创 建 sServer.csr 和 server.crt 文 件 。 在 生成 server.csr 
时 ，-subj 参 数 中 “CN” 指定 的 名 字 需 为 Master 所 在 的 主机 名 。 


# openssl req -new -key server.key -Subj "/CN=k8s-master 


# openssl x509 -req -in server.csr -CA ca.crt -CAkey ca. 


全 部 执行 完 后 会 生成 6 个 文件 : ca.crt、ca.key、ca.srl、server.crt、 


9eIVeLI.C9T、 server.key o 


将 这 些 文件 复制 到 一 个 目录 中 例如 /var/run/kubernetes/) ， 然 后 设 
置 kube-apiserver 的 三 个 启动 参数 “--client-ca-file”“--tls-cert-file” 和 “--tls- 
Private-key-file”， 分 别 代表 CA 根 证 书 文 件 、 服 务 端 证 书 文件 和 服务 端 私 
钥 文件 : 





--client_ca_file=/var/run/kubernetes/ca.crt 
--tls-private-key-file=/var/run/kubernetes/server.key 


--tls-cert-file=/var/run/kubernetes/server.crt 


同时 ， 可 以 关 掉 非 安全 端口 8080， 设 置 安全 端口 为 443〈 默 认为 


6443) : 


--insecure-port=0 


--secure-port=443 


最 后 重启 kube-apiserver 服 务 。 
2) 设置 kube-controller-manager 的 客户 端 证 书 、 私 钥 和 启动 参数 


$ openssl genrsa -out cs_client.key 2048 
$ openssl req -new -key cs_client.key -subj "/CN=k8s-nod 


$ openssl x509 -req -in cs_client.csr -CA ca.crt -CAkey 


其 中 ， 在 生成 cs_client.crt 时 ，-CA 参 数 和 -CAkey 参 数 使 用 的 是 
apiserver 的 ca.crt 和 ca.key 文 件 。 然 后 将 这 些 文件 复制 到 一 个 目录 中 《 例 
如 /varrun/kubernetes/) 。 


接 下 来 创建 /etc/kubernetes/kubeconfig 文 件 (kube-controller-manager 
与 kube-scheduler 共 用 ) ， 配 置 客 户 病 证 书 等 相关 参数 ， 内 容 如 下 : 


apiVersion: v1 
kind: Config 
users: 
- name: controllermanager 
user: 
client-certificate: /var/run/kubernetes/cs_client.cr 


client-key: /var/run/kubernetes/cs_client.key 


clusters: 


- name: local 
cluster: 
certificate-authority: /var/run/kubernetes/ca.crt 
contexts: 
- context: 
cluster: local 
user: controllermanager 
name: my-context 


current-context: my-context 


然后 ， 设 置 kube-controller-manager 服 务 的 启动 参数 ， 注 意 ，-- 
master 的 地 址 为 HITPS 安 全 服务 地 址 ， 不 使 用 非 安全 地 址 
http://192.168.18.3: 8080. 


--master=https://192.168.18.3:443 
--service_account_private_key_file=/var/run/kubernetes/s: 
--root-ca-file=/var/run/kubernetes/ca.crt 


--kubeconfig=/etc/kubernetes/kubeconfig 


重启 kube-controller-manager 服 务 。 
3) 设置 kube-scheduler 启 动 参数 


kube-scheduler 复 用 上 一 步 kube-controller-manager 创 建 的 客户 端 证 
书 ， 配 置 局 动 参数 : 


--master=https://192.168.18.3:443 


--kubeconfig=/etc/kubernetes/kubeconfig 


重启 kube-scheduler 服 务 。 
4) 设置 每 台 Node 上 kubelet 的 客户 端 证 书 、 私 钥 和 启动 参数 


首先 复制 kube-apiserver 的 ca.crt 和 ca.key 文 件 到 Node 上， 在 生成 
kubelet_client.crt 时 -CA 参数 和 -CAkey 参 数 使 用 的 是 apiserver 的 ca.crt 和 
ca.key 文 件 。 在 生成 kubelet_client.csr 时 -subj 参 数 中 的 %CN” 设 置 为 本 
Node 的 IP 地 址 。 


$ openssl genrsa -out kubelet_client.key 2048 
$ openssl req -new -key kubelet_client.key -subj "/CN=19 


$ openssl x509 -req -in kubelet_client.csr -CA ca.crt -C 


将 这 些 文件 复制 到 一 个 目录 中 《例如 /varrun/kubernetes/) 。 


接 下 来 创建 /etc/kubernetes/kubeconfig 文 件 (kubelet 和 kube-proxy 进 
FERH) ， 配 置 客 户 问 证 书 等 相关 参数 ， 内 容 如 下 : 





apiVersion: v1 
kind: Config 
users: 
- name: kubelet 
user: 
client-certificate: /etc/kubernetes/ssl_keys/kubelet. 
client-key: /etc/kubernetes/ssl_keys/kubelet_client. 
clusters: 
- name: local 


cluster: 


certificate-authority: /etc/kubernetes/ssl_keys/ca.c 
contexts: 
- context: 
cluster: local 
user: kubelet 
name: my-context 


current-context: my-context 


然后 ， 设 置 kubelet 服 务 的 启动 参数 : 


--api_servers=https://192.168.18.3:443 


--kubeconfig=/etc/kubelet/kubeconfig 


最 后 重启 kubelet 服 务 。 
5) 设置 kube-proxy 的 启动 参数 
kube-proxy 复 用 上 一 步 kubelet 创 建 的 客户 端 证 书 ， 配 置 局 动 参数 : 


--master=https://192.168.18.3:443 


--kubeconfig=/etc/kubernetes/kubeconfig 


重启 kube-proxy 服 务 。 


至 此 ， 一 个 基于 CA 的 双 癌 数字 证 书 认证 的 Kubernetes 集 群 环 境 就 搭 
建 完 成 了 。 


6) 设置 kubectl 客 户 端 使 用 安全 方式 访问 apiserver 


在 使 用 kubectl 对 Kubernetes 集 和 群 进 行 操作 时 ， 默 认 使 用 非 安全 端口 
8080 对 apiserver 进 行 访问 ， 也 可 以 设置 为 安全 访问 apiserver 的 模式 ， 需 
要 设置 3 个 证 书 相 关 的 参数 “ certificate-authority”“--client-certificate” 和 “- 
-client-key”， 分 别 表 示 用 于 CA 授权 的 证 书 、 客 户 问 证 书 和 客户 问 密 铀 。 








e --certificate-authority: 使 用 为 kube-apiserver 生 成 的 ca.crt 文 件 。 

e --client-certificate: 使 用 为 kube-controller-manager 和 后 成 的 cs_client.crt 
SF 

--client-key: 使 用 为 kube-controller-manager 生 成 的 cs_client.key 文 
a 


同时 ， 指 定 apiserver 的 URL 地 址 为 HTTPS 安 全 地 址 (例如 
https://k8s-master: 443) ， 最 后 输入 需要 执行 的 子 命令 ， 即 可 对 
apiserver 进 行 安 全 访问 了 : 





# kubectl --server=https://k8s-master:443 --certificate- 
NAME STATUS AGE 


k8s-node-1 Ready 1h 


2. 基 于 HTTP BASE 或 TOKEN 的 简单 认证 方式 


除了 基于 CA 的 双向 数字 证 书 认 证 方式 ，Kubernetes 也 提供 了 基于 
HTTP BASE 或 TOKEN 的 简单 认证 方式 。 各 组 件 与 apiserver 之 间 的 通信 
方式 仍然 采用 HTTPS， 但 不 使 用 CA 数字 证 书 。 


采用 基于 HTTP BASE 或 TOKEN 的 简单 认证 方式 时 ，API Server 对 外 
暴露 HITTPS 端 口 ， 客 户 端 提 供用 户 名 、 密 码 或 Token 来 完成 认证 过 程 。 
需要 说 明 的 是 ，kubectl 命 令 行 工 具 比较 特殊 ， 它 同时 支持 CA 双向 认证 








与 简单 认证 两 种 模式 与 apiserver 通 信 ， 其 他 客户 端 组件 只 能 配置 为 双 辐 
安全 认证 或 非 安全 模式 与 apiserver 通 信 。 


基于 HTTP BASE 认 证 的 配置 过 程 如 下 。 


(1) 创建 包括 用 户 名 、 A A auth_file， 放 置 在 
合适 的 目录 中 ， 例 如 /etc/kuberntes 目 录 。 需 要 注意 的 是 ， 这 是 一 个 纯 文 
本 文件 ， 用 户 名 、 密 码 都 是 明文 。 











# vi /etc/kubernetes/basic_auth_file 
admin, admin, 1 


system, system, 2 


(2) 设置 kube-apiserver 的 局 动 参数 “--basic_auth_file”， 使 用 上 述 文 
件 提供 安全 认证 : 


--Secure-port=443 


--basic auth file=/etc/kubernetes/basic auth file 


然后 ， 重 启 API Server 服 务 。 





(3) 使 用 kubectl 通 过 指定 的 用 户 名 和 密码 来 访问 API Server: 


# kubectl --server=https://192.168.18.3:443 --username=a 


基于 TOKEN 认 证 的 配置 过 程 如 下 。 


(1) 创建 包括 用 户 名 、 密 码 和 UID 的 文件 token_auth file， 放 置 在 
适 的 目录 中 ， 例 如 /etckuberntes 目 录 。 需 要 注意 的 是 ， 这 是 一 个 纯 文 











本 文件 ， 用 户 名 、 密 码 都 是 明文 。 


$ cat /etc/kubernetes/token auth file 
admin, admin, 1 


system, system, 2 


(2) 设置 kube-apiserver 的 启动 参数 “--token_auth_file”， 使 用 上 述 
文件 提供 安全 认证 : 


--Secure-port=443 


--token auth file=/etc/kubernetes/token auth file 


然后 ， 重 启 API Server 服 务 。 
(3) 用 curl 验 证 和 访问 API Server: 


$ curl -k --header "Authorization:Bearer admin" https:// 


{ 
"major": "1", 
"minor": "3", 
"gitVersion": "v1.3.3", 


"gitCommit": "c6411395e09da356c608896d3d9725acab821418 
"gitTreeState": "clean", 

"buildDate": "2016-07-22T20:22:25Z", 

"goVersion": "go1.6.2", 

"compiler": "gc", 


"platform": "linux/amd64" 


2.1.4 Kubernetes 的 版 本 升级 


Kubernetes 的 版 本 升级 需要 考虑 到 当前 集群 中 正在 运行 的 容器 不 受 
影响 。 应 对 集群 中 的 各 Node 逐 个 进行 隅 离 ， 然 后 等 竺 在 其 上 运行 的 容器 
全 部 执行 完成 ， 再 更 新 该 Node 上 的 kubelet 和 kube-proxy 服 务 ， 将 全 部 
Node 都 更 新 完成 后 ， 最 后 更 新 Master 的 服务 。 





。 通过 官网 获取 最 新 版 本 的 二 进 制 包 kubernetes.tar.gz， 解 压缩 后 提取 
服务 二 进 制 文件 。 

。 逐个 隔离 Node， 等 竺 在 其 上 运行 的 全 部 容器 工作 完成 ， 更 新 kubelet 
和 kube-proxy 服 务 文件 ， 然 后 重 局 这 两 个 服务 。 

e 更 新 Master 的 kube-apiserver、kube-controller-manager、kube- 
scheduler 服 务 文件 并 重启 。 





2.1.5 内 网 中 的 Kubernetes 相 关 配 置 


Kubernetes 在 能 够 访问 Intermet 网 络 的 环境 中 使 用 起 来 非常 方便 ， 一 
方面 在 docker.io 和 gcr.io 网 站 中 已 经 存在 了 大 量 官方 制作 的 Docker 镜 像 ， 
另 一 方面 GCE、AWS 提 供 的 云 平台 已 经 很 成 部 了， 用 户 通 过 租用 一 定 
的 空间 来 部 普 Kubernetes 集 群 也 很 简便 。 





但 是 ， 许 多 企业 内 部 由 于 安全 性 的 原因 无 法 访问 Internet。 对 于 这 些 
企业 就 需要 通过 创建 一 个 内 部 的 私有 Docker Registry， 并 修改 一 些 
Kubernetes 的 配置 ， 来 启动 内 网 中 的 Kubernetes 集 群 。 

1.Docker Private Registry (私有 Docker 镜 像 库 ) 

使 用 Docker 提 供 的 Registry 镜 像 创 建 一 个 私有 镜像 仓库 。 

详细 的 安装 步骤 请 参考 Docker 的 官方 文档 
https://docs.docker.com/registry/deploying/ - 

2.kubelet 配 置 


由 于 在 Kubernetes 中 是 以 Pod 而 不 是 Docker 容 器 为 管理 单元 的 ， 在 
kubelet 创 建 Pod 时 ， 还 通过 启动 一 个 名 为 google_containers/pause 的 镜像 
来 实现 Pod 的 概念 。 





该 镜像 存在 于 谷歌 镜像 库 http:/gcr.io 中 ， 需 要 通过 一 台 能 够 连 上 


Internet 的 服务 器 将 其 下 载 ， 导 出 文件 ， 再 push 到 私有 Docker Registry 中 
za 


之 后 ， 可 以 给 每 台 Node 的 kubelet 服 务 的 启动 参数 加 上 -- 
pod_infra_container_image 人 参数， 指定 为 私有 Docker Registry 中 pause 镜 像 
的 地 址 。 例 如 : 


# cat /etc/kubernetes/kubelet 


KUBELET_ARGS="- -api-servers=http://192.168.18.3:8080 --hi 


如 果 该 镜像 无 法 下 载 ， 则 也 可 以 从 Docker Hub 上 进行 下 载 : 
# docker pull kubeguide/google_containers/pause-amd64:3.| 


修改 kubelet 配 置 文件 中 的 





pod_infra_container_image 参 数 如 下 : 
--pod_infra_container_image=kubeguide/google_containers/ 
然后 重启 kubelet 服 务 : 


# systemctl restart kubelet 


通过 以 上 设置 束 在 内 网 环境 中 搭建 了 一 个 企业 内 部 的 私有 容器 云 平 


op 


2.1.6 ”Kubernetes 核 心服 务 配 置 详解 


我 们 在 2.1.2 节 对 Kubernetes 各 服务 启动 进程 的 关键 配置 参数 进行 了 
简要 说 明 ， 实 际 上 Kubernetes 的 每 个 服务 都 提供 了 许多 可 配置 的 参数 。 
这 些 参数 涉及 安全 性 、 性 能 优化 及 功能 扩展 Plugin) 等 方方面面 。 全 
面 理 解 和 掌握 这 些 参数 的 含义 和 配置 ， 无 论 对 于 Kubernetes 的 生产 部 署 
还 是 日 常 运 维 都 有 很 好 的 帮助 。 


每 个 服务 的 可 用 参数 都 可 以 通过 运行 “cmd--help” 命 令 进行 查看 ， 其 
中 cmd 为 具体 的 服务 启动 命令 ， 例 如 kube-apiserver、kube-controller- 
manager、kube-scheduler、kubelet、kube-proxy 等 。 另 外 ， 也 可 以 通过 在 
命令 的 配置 文件 〈 例 如 /etckubernetes/kubelet 等 ) 中 添加 “-- 参 数 名 = 参数 
取 值 ?的 语句 来 完成 对 某 个 参数 的 配置 。 








本 节 将 对 Kubernetes 所 有 服务 的 参数 进行 全 面 介绍 ， 为 了 方便 学 习 
和 查阅 ， 对 每 个 服务 的 参数 用 一 个 小 节 进 行 详细 说 明 。 


1. 公 共 配 置 参 数 


公共 配置 参数 适用 于 所 有 服务 ， 如 表 2.3 所 示 的 参数 可 用 于 kube- 
apiserver、kube-controller-manager、kube-scheduler、kubelet、kube- 
proxy。 本 节 对 这 些 参数 进行 统一 说 明 ， 不 再 在 每 个 服务 的 参数 列表 中 
列 出 。 


表 2.3 ”公共 配置 参数 表 


参数 名 和 取 值 示例 说 了 明 
--log-backtrace-at=:0 记录 日 志 每 到 “file: 行 号 ”时 打印 一 次 stack trace 
--log-dir= 日 志文 件 路 径 
--log-flush-frequency=5s 设置 flush 日 志文 件 的 时 间 间 隔 
--logtostderr=true 设置 为 tue 则 表示 将 日 志 输 出 到 stderr， 不 输出 到 日 志文 件 

















参数 名 和 取 值 示 例 说 明 
--alsologtostderr=false 设置 为 tue 则 表示 将 日 志 输 出 到 文件 的 同时 输出 到 stderr 
--stderrthreshold=2 将 该 threshold 级 别 之 上 的 日 志 输 出 到 stderr 
--v=0 glog 日 志 级 别 
--vmodule= glog 基于 模块 的 详细 日 志 级 别 
--version=[false] 设置 为 true 则 将 打印 版 本 信息 然后 退出 























2.kube-apiserver 启 动 参数 
对 kube-apiserver 局 动 参数 的 详细 说 明 如 表 2.4 所 示 。 


表 2.4 对 kube-apiserver 启 动 参数 的 详细 说 明 


参数 名 和 取 值 示例 

--admission-control="AlwaysAdmit" 对 发 送 给 API Server 的 任何 请 求 进行 准 入 控制 ， 配 置 为 一 个 “ 准 入 控制 器 ”的 列 
R, 多 个 准 入 控制 器 时 以 逗号 分 隔 。 多 个 准 入 控制 器 将 按 顺 序 对 发 送 给 API Server 
的 请 求 进行 拦截 和 过 滤 ， 若 某 个 准 入 控制 器 不 允许 该 请 求 通过 ， 则 API Server 拒 
绝 此 调用 请 求 。 可 配置 的 准 入 控制 器 如 下 。 

AlwaysAdmit: 允许 所 有 请 求 。 

AlwaysPullImages: 在 启动 容器 之 前 总 是 去 下 载 镜像 ， 相当 于 在 每 个 容器 的 配 

‘i imagePullPolicy=Always。 

AlwaysDeny: 禁止 所 有 请 求 ， 一 般 用 于 测试 。 

DenyExecOnPrivileged: 它 会 拦截 所 有 想 在 privileged container 上 执行 命令 的 

请 求 。 如 果 你 的 集群 支持 privileged container， 你 又 希望 限制 用 户 在 这 些 

privileged container 上 执行 命令 ， 那 么 强烈 推荐 你 使 用 它 。 

ServiceAccount: 这 个 plug-i 将 serviceAccounts 实现 了 自动 化 ， 如 果 你 想 要 

使 用 ServiceAccount 对 象 ， 那 么 强烈 推荐 你 使 用 它 。 

SecurityContextDeny: 这 个 插件 将 使 用 了 SecurityContext 的 Pod 中 定义 的 选 

项 全 部 失效 。SecurityContext 在 container 中 定义 了 操作 系统 级 别 的 安全 设 定 

(uid. gid. capabilities, SELinux 等 )。 

ResourceQuota: 用 于 配额 管理 目的 ， 作 用 于 Namespace 上 ， 它 会 观察 所 有 的 

请 求 , 确保 在 namespace 上 的 配额 不 会 超标 。 推荐 在 admission control 参数 列 

表 中 这 个 插件 排 最 后 一 个 。 

LimitRanger: 用 于 配额 管理 ,作用 于 Pod 与 Container 上 ,确保 Pod 45 Container 

上 的 配额 不 会 超标 。 

NamespaceExists (已 过 时 ):; 对 所 有 请 求 校 验 namespace 是 否 已 存在 ， 如 果 不 

存在 则 拒绝 请 求 。 已 合并 至 NamespaceLifecycle。 

NamespaceAutoProvision (已 过 时 ): 对 所 有 请 求 校 验 namespace， 如 果 不 存 

在 则 自动 创建 该 namespace， 推 荐 使 用 NamespaceLifecycle。 








--admission-control="AlwaysAdmit” 3 NamespaceLifecycle: 如 果 尝 试 在 一 个 不 存在 的 namespace 中 创建 资源 对 象 ， 
则 该 创建 请 求 将 被 拒绝 。 当 删除 一 个 namespace PY, RAZMER namespace 
中 的 所 有 对 象 ， 包 括 Pod. Service 等 。 
如 果 启 用 多 种 准 入 选项 ， 则 建议 加 载 的 顺序 是 : 
~-admission-control=NamespaceLifecycle LimitRanger.SecurityContextDeny.ServiceA 
ccount.ResourceQuota 


与 难 入 控制 规则 相关 的 配置 文件 


用 于 广播 给 集群 的 所 有 成 员 自己 的 TP 地 址 , 不 指定 该 地 址 将 使 用 “bind-address” 
定义 的 于 地址 
—allow-privileged=false 如 果 设置 为 tue， 则 Kubemetes 将 允许 在 Pod 中 运行 拥有 系统 特权 的 容器 应 用 ， 


集 竹中 运行 的 API Server 数量 


--authentication-token-webhook-cache- 将 webhook token authenticator 返回 的 响应 保存 在 缓存 内 的 时 间 ， 默 认为 两 分 钟 
tt=2m0s 

Webhook 相关 的 配置 文件 ， 将 用 于 token authentication 
file="" 


--authorization-mode="AlwaysAllow" 到 API Server 的 安全 访 阅 的 认证 模式 列表 ， 以 逗号 分 隔 ， 可 选 值 包括 : 
AlwaysAllow, AlwaysDeny. ABAC. Webhook. RBAC 


当 --authorization-mode 设置 为 ABAC 时 使 用 的 csv 格式 的 授权 配置 文件 


TEA 
authorization-rbac-super-user="" 当 --authorization-mode 设置 为 RBAC 时 使 用 的 超级 用 户 名 ， 使 用 该 用 户 名 可 以 不 
--authorization-webhook-cache-authorized | 将 webhook authorizer 返回 的 “已 授权 ”响应 保存 在 缓存 内 的 时 间 , 默认 为 5 分 钟 。 
ee 
--authonzation-webhook-cache-unauthor | 将 webhook authorizer iA [If) “RHE” ECE EAT, BRU 30 秒 
设置 该 文件 用 于 通过 HTTP 基本 认证 的 方式 访问 API Server 的 安全 端口 
Kubemetes API Server 在 本 地 址 的 6443 端口 开启 安全 的 HTTPS 服务 ， 默 认为 000.0 
TLS 证 书 所 在 的 目录 ， 默 认为 warmunkubermetes。 如 果 设置 了 -ts-cert-fle 和 
一 tls-private-key-file， 则 该 设置 将 被 忽略 


云 服务 商 的 名 称 ， 不 配置 则 表示 不 使 用 云 服 务 商 


CORS (HIIHTO) 设置 允许 访问 的 源 域 列表 ， 用 去 号 分 隔 ， 并 可 使 用 正则 
表达 式 匹 配子 网 。 如 果 不 指定 ， 则 表示 不 启用 CORS 
设置 内 存 中 缓存 的 JSON 对 象 的 个 数 





续 表 
参数 名 和 取 值 示例 


设置 为 tme 表示 启用 垃圾 回收 器 .必须 与 kube-controller-manager 的 该 参数 设置 为 
相同 的 值 


设置 为 tue 表示 启用 swaggerui 网 页 ， 可 通过 API Server 的 URL/swagger-ui 访问 





到 eted 安全 连接 使 用 的 SSL key 文件 
以 逗号 分 陋 的 eted 服务 URL 列表 ，eted 服务 以 http://ip:port 格式 表示 
--etcd-servers-overrides=[ RMB M ecd 服务 的 设置 ， 以 逗号 分 隔 。 单 个 机 六 格式 为 : group/resource 
ERRED js5ervers， 其 中 servers 格式 为 http://ip:port， 以 分 号 分 隔 
--event-ttl=1h0m0s Kubemetes API Server 中 各 种 事件 (通常 用 于 审计 和 追踪 ) 在 系统 中 保存 的 时 间 ， 
RUA 1 小 时 


设置 keystone 鉴 权 搬 件 地 址 ， 实 验 用 


--external-hostname="" 用 于 生成 该 Master 的 对 外 URL 地 址 ， 例 如 用 于 swagger api 文档 中 的 URL 地 址 。 


绑 定 的 不 安全 全 地 址 , 与 -insecure-port 共同 使 用 ,默认 为 localhost. 设置 为 0.0.0.0 
表示 使 用 全 部 网 络 接口 

提供 非 安 全 认证 访问 的 监听 端口 ， 默 认为 8080。 应 在 防火 墙 中 进行 配置 ， 以 使 得 
外 部 客户 端 不 可 以 通过 非 安全 端口 访问 API Server 


InitialResources 所 需 指 标 保存 在 influxdd 中 的 数据 库 名 称 ， 默 认为 k8s 

G2 Hava M URL At 
--ir-influxdb-host="localhost:8080/apiv | InitialResources 所 需 指标 所 在 imfluxdb 的 URL ht, MUA localhost:8080/ 
l/proxy/namespaces/kube-system/servic | api'v1/proxy/namespaces/kube-system/services/monitoring-influxdb:api 
es/monitonng-influxdb:api” 


设置 为 tue 表示 从 相同 的 namespace 内 的 数据 进行 估算 
连接 infhuxdb 数据 库 的 密码 

0 

k 


连接 influxdb 数据 库 的 用 户 名 


--ir-namesp. 示 C 进行 


~-kubemetes-service- 设置 Master 服务 是 否 使 用 NodePort 模式 ， 如 果 设 置 ， 则 Master 服务 将 英 射 到 物 
理 机 约 端 口号 ， 设 置 为 0 表示 以 ClusterIP 的 形式 启动 Master 服务 


", 
m m 


| 参数 名 和 取信 二 | 说 图 
--long-running-request-regexp="()((w | 以 正则 表达 式 配 置 哪些 需要 长 时 间 执 行 的 讲求 不 会 被 系统 进行 超时 处 理 
atchiproxy)(/IS)l(logs ?Iportforwardlexec|a 
ttach)/?$)" 


--master-service-namespace="default" 设置 Master 服务 所 在 的 namespace, MU 4% default 


a ee 设置 为 非 0 的 值 表示 限制 每 个 客户 端 连 接 的 带宽 为 xx 字 节 / 秒 ， 目 前 仅 用 于 需要 
长 时 间 执 行 的 请 求 

同时 处 理 的 最 大 请 求 数量 ， 默 认为 400， 超 过 该 数量 的 请 求 将 被 拒绝 。 设 置 为 0 
表示 无 限制 


最 小 请 求 处 理 超时 时 间 ， 单 位 为 秒 ， 默 认为 1800 秒 ， 目 前 仅 用 于 watch request 
handler， 其 将 会 在 该 时 间 值 上 加 一 个 随机 时 间作 为 请 求 的 超时 时 间 

该 文件 内 设置 鉴 权 机 构 ，OpenID Server 的 证 书 将 被 其 中 一 个 机 构 进 行 验证 。 如 果 
不 设置 ， 则 将 使 用 主机 的 root CA 证 书 


打开 性 能 分 析 ， 可 以 通过 <host>:<port>/debugjpproD 地 址 查看 程序 栈 、 线 程 等 系 


设置 为 tue 表示 服务 器 将 尽 可 能 修复 无 效 或 格式 错误 的 update request， 以 通过 正 
确 性 校 验 ， 例 如 在 一 个 update request 中 将 一 个 已 存在 的 UD HRB AZ 

一 组 key=value 用 于 运行 时 的 配置 信息 。 apis/=groupVersion>/=resouree> 可 用 于 打 
开 或 关闭 对 某 个 API 版 本 的 支持 。apifall 和 apilegacy 特别 用 于 支持 所 有 版 本 的 
API 或 支持 旧版 本 的 API 


设置 API Server 使 用 的 HTTPS 安全 模式 端口 号 ， 设 置 为 0 表示 不 启用 HITPS 


--secure-port=6443 
--service-account-key-file="" 包含 PEM-encoded x509 RSA 公 钥 和 私 钥 的 文件 路 径 ， 用 于 验证 Service Account 
的 token。 不 指定 则 使 用 --tls-private-key-file 指定 的 文件 


设置 为 ue 上 时， 系统 会 到 eted 验证 ServiceAccount token 是 否 存 在 


i Service 的 Cluster IP (41 IP) 池 ， 例 如 169.169.0.0116， 这 个 P 地 址 池 不 能 与 物 
理 机 所 在 的 网 络 重合 
Service 的 NodePort 能 使 用 的 主机 端口 号 范围 , 默认 为 30000 一 32767, 包括 30000 
和 32767 


如 果 指 定 ， 则 通过 SSH 使 用 指定 的 秘 钥 文件 对 Node 进行 访问 
如 果 指 定 ， 则 通过 SSH 使 用 指定 的 用 户 名 对 Node 进行 访问 
设置 持久 化 存储 类 型 ， 可 选项 为 eed2 (默认 )、eted3 


--storage-media-type="applicationjson” | 持久 化 存储 中 的 保存 格式 ， 默 认为 applicationjson。 某 些 资源 类 型 只 能 使 用 
application/json 格式 进行 保存 ， 将 忽略 这 个 参数 的 设置 


--storage-versions="apps/vlalphal.authe | 持久 化 存储 的 资源 版 本 号 ， 以 分 组 形式 标记 ， 例 

ntication k8s.io/vlbetal.authorization k8 | 4”group1/version1.group2/version2....” 

sjio/vlbetal.autoscaling/vl.batch/vl.co 

mponentconfig/vlalphal.extensions/v1b 

etal policy/v1alphal rbac.authorization. 

k8s.io/vlalphal.vl” 

--tls-cert-file="" 包含 x509 证 书 的 文件 路 径 ， 用 于 HTTPS 认证 

—tls-private-key-file=™ 

--token-auth-file="" 用 于 访问 API Server 安全 端口 的 token 认证 文件 路 径 

--watch-cache[=true] HEJ tue 表示 将 watch 进行 缓存 

—watch-cache-sizes=[] 设置 各 资源 对 象 watch 缓存 大 小 的 列表 ， 以 逗号 分 隔 ， 每 个 资源 对 象 的 设置 格式 
为 resource#size, “4 watch-cache 设置 为 true 时 生效 














3.kube-controller-manager 启 动 参数 


对 kube-controller-manager 启 动 参数 的 详细 说 明 如 表 2.5 所 示 。 


422.5 ”对 kube-controller-manager 启 动 参数 的 详细 说 明 


参数 名 和 取 值 示例 


说 





--address=0.0.0.0 


监听 的 主机 IP 地 址 ， 默 认为 0.0.0.0 表示 使 用 全 部 网 络 接口 





--allocate-node-cidrs=false 








设置 为 tue 表示 使 用 云 服务 商 为 Pod 分 配 的 CIDRs, MA FAA 











--cloud-config=""" 


云 服务 商 的 配置 文件 路 径 ， 仅 用 于 公有 云 





--cloud-provider=""" 


云 服务 商 的 名 称 ， 仅 用 于 公有 云 





--cluster-cidr=<nil> 











集群 中 Pod 的 可 用 CIDR 范围 








--cluster-name="kubermetes” 


集群 的 名 称 ， 默 认为 kubernetes 





--concurent-deployment-synes=5 


设置 允许 的 并 发 同步 deployment 对 象 的 数量 ， 值 越 大 表示 同步 操作 越 快 ， 但 将 会 
消耗 更 多 的 CPU 和 网 络 资源 








--concurrent-endpoint-synes=5 





设置 并 发 执行 Endpoint 同步 操作 的 数量 ， 值 越 大 表示 同步 操作 越 快 ， 但 将 会 消耗 
更 多 的 CPU 和 网 络 资源 





--concurrent-re-synes=5 


并 发 执行 RC 同步 操作 的 协 程 数 ， 值 越 大 表示 同步 操作 越 快 ， 但 将 会 消耗 更 多 的 
CPU 和 网 络 资源 





--concurrent-namespace-syncs=2 


设置 允许 的 并 发 同步 namespace 对 象 的 数量 ， 值 越 大 表示 同步 操作 越 快 ， 但 将 会 
消耗 更 多 的 CPU 和 网 络 资源 





--concurrent-r¢e-synes=5 





设置 允许 的 并 发 同步 replication controller 对 象 的 数量 , 值 越 大 表示 同步 操作 越 快 ， 
但 将 会 消耗 更 多 的 CPU 和 网 络 资源 





--concurrent-replicaset-synes=5 

















设置 允许 的 并 发 同步 replica set 对 象 的 数量 , 值 越 大 表示 同步 操作 越 快 , 但 将 会 消 
耗 更 多 的 CPU 和 网 络 资源 


--concurrent-resource-quota-synes=5 设置 允许 的 并 发 同步 resource quota 对 象 的 数量 , 值 越 大 表示 更 快 地 进行 同步 操作 ， 
但 将 会 消耗 更 多 的 CPU 和 网 络 资源 
设置 为 tue 表示 使 用 allocate-node-cidrs 进行 CIDRs 的 分 配 ， 仅 用 于 公有 云 
DaemonSet 的 查询 缓 在 大 小 ， 默 认为 1024。 值 址 大 表示 DaemonSet 响应 越 快 ， 内 
存 消耗 也 越 大 


设置 为 bue 表示 启用 hostPath PV provisioning 机 制 , 仅 用 于 测试 ,不 可 用 于 多 Node 
的 集群 环境 
--flex-volume-plugin-du="/usrlibexeckku | 设置 flex volume 插件 应 搜索 其 他 第 三 方 volume 插件 的 全 路 径 
bemetes/inubelet-plugins/vohime/exec!” 


--horizontal-pod-autoscaler-syne-period | Pod 自动 扩容 器 的 Pod 数量 的 同步 时 间 人 间隔， 默认 为 30 秒 


发 送 到 API Server 的 每 秒 的 请 求 数量 ， 默 认为 30 


--kube-api-content-type="application'vn | 发 送 到 API Server 的 请 求 内 容 类 型 
dkubermmetesprotobuf 


--kube-api-aps=20 与 API Server 通信 的 QPS 值 ， 默 认为 20 
--kubeconfiz="" kubeconfig 配置 文件 路 径 ， 在 配置 文件 中 包括 Master 地 址 信息 及 必要 的 认证 信息 
设置 为 tue 表示 进行 leader 选举 ， 用 于 多 个 Master 组 件 的 高 可 用 部 署 


leader 选举 过 程 中 非 leader 等 待 选举 的 时 间 间 隔 , 默认 为 15 秒 , 当 leader-elect=true 
时 生效 


--leader-elect-renew-deadline=10s leader 选举 过 程 中 在 停止 leading 角色 之 前 再 次 renew 的 时 间 间 后， 应 小 于 或 等 于 
jeader-elect-ljease-duration， 默 认为 10 秒 ， 当 leader-elect=true 时 生效 

--leader-elect-retry-period=2s leader 选举 过 程 中 在 获取 leader 角色 和 renew 之 间 的 等 待 时 间 ， 默 认为 两 秒 ， 当 
leader-elect=true 时 生效 

-aaa 

--min-resyne-period=12h0m0s 最 小 重新 闻 步 的 时 间 间 隔 ， 实 际 重新 同步 的 时 间 为 MinResyncPeriod〔 默 认为 12 
小 时 ) 到 2xMinResyncPeriod (默认 24 小 时 ) 之 间 的 一 个 随机 数 

~-namespace-syne-peniod=Sm0s namespace 生命 周期 更 新 的 同步 时 间 间 隔 ， 默 认为 5 分 钟 


Node CIDR 的 子 网 掩 码 设置 ， 默 认为 24 





监控 Node 状态 的 时 间 间 隔 , 默认 为 40 秒 , 超过 该 设置 时 间 后 ,controller-manager 
会 把 Node 标记 为 不 可 用 状态 。 此 值 的 设置 有 如 下 要 求 : 

它 应 该 被 设置 为 kubelet 汇报 的 Node 状态 时 间 间 隔 (参数 一 node-status-update- 
frequency=10s) 的 入 售 ，N 为 kubelet 状态 汇报 的 重 试 次 数 


同步 NodeStatus 的 时 间 间 陋 ， 默 认为 5 秒 


Node 启动 的 最 大 允许 时 间 ， 超 过 此 时 间 无 响应 则 会 标记 Node 为 不 可 用 状态 ( 启 
动 失败 )， 默 认为 1 分钟 
--node-sync-period=10= Node 信息 发 生变 化 时 例如 新 Node 加 入 集群 》controller-manager 同步 各 Node 


--pod-eviction-timeout=5m0s 在 发 现 一 个 Node 失效 以 后 , 延迟 一 段 时 间 , 在 超过 这 个 参数 指定 的 时 间 后 ,删除 
lt Node 上 的 Pod， 默 认为 5 分钟 


controller-manager 监 昕 的 主机 端口 号 ， 默 认为 10252 


--profiling=true 打开 性 能 分 析 ， 可 以 通过 <host>:<port>/debug/pprofi 地 赴 查 看 程序 栈 、 线 程 等 系统 
使 用 nfs scrubber 的 Pod 等 增加 1Gi 空间 在 ActiveDeadlineSeconds 上 增加 的 时 间 ， 
默认 为 30 秒 
使 用 hostPath recycler 的 Pod 的 最 小 ActiveDeadlineSeconds 秒 数 ， 默 认为 60 秒 。 
=60 实验 用 


使 用 nfs recycler 的 Pod 的 最 小 ActiveDeadlineSeconds $t, Ri 3 300 # 


使 用 hostPath recycler 的 Pod 的 模板 文件 全 路 径 ， 仅 用 于 实验 
path=" 


使 用 nfs recycler 的 Pod 的 模板 文件 全 路 生 


--pv-recycler-timeout-increment-hostpath | 使 用 hostPath scrubber 的 Pod 每 增加 1Gi 空间 在 ActiveDeadlineSeconds 上 增加 的 
=30 时 间 ， 默 认为 30 秒 。 实 验 用 


同步 PV A PVC (容器 声明 的 PV》 的 时 间 亲 陋 


i 设置 replica sets 查询 缓存 的 大 小 ， 默 认为 4096， 值 越 大 表示 查询 操作 越 快 ， 但 将 
设置 replication controller 查询 级 存 的 大 小 ， 默 认为 4096， 值 越 大 表示 查询 操作 越 
=4096 快 ， 但 将 会 消耗 更 多 的 内 存 


resource quota 使 用 信息 同步 的 时 间 和 间隔， 默认 为 5 分 名 

根 CA 证 书 文件 路 径 ， 将 被 用 于 Service Account 的 token secret 中 

用 于 给 Service Account token 签名 的 PEM-encoded RSA 私 钥 文 件 路 径 
Service i IP #8 

同步 service 与 外 部 load balancer 的 时 间 间 隔 ， 默 认为 5 分 名 


--terminated-pod-ge-threshold=12500 设置 可 保存 的 终止 Pod 的 数量 ， 超 过 该 数量 ， 垃 圾 回收 器 将 开始 进行 删除 操作 。 
设置 为 不 大 于 0 的 值 表 示 不 启用 该 功能 





4.kube-scheduler 启 动 参数 
对 kube-scheduler 局 动 参数 的 详细 说 明 如 表 2.6 所 示 。 


422.6 ”对 kube-scheduler 启 动 参数 的 详细 说 明 


监听 的 主机 bht, RUA 0.0.0.0 表示 使 用 全 部 网 络 接口 

--algorithm-provider="DefaultProvider” | 设置 调度 算法 ， 默 认为 DefaultProvider 

--failure-domains="kubemetes.io/hosmam | 表示 Pod 调度 时 的 亲和力 参数 。 在 调度 Pod 时 ， 如 果 两 个 Pod 有 相同 的 亲和力 参 

e.failure-domain.betakubemetes.io/zonef | 数 ， 那么 这 两 个 Pod 会 被 调度 到 相同 的 Node k: 如 果 两 个 Pod 有 不 同 的 亲和力 参 

ailure-domain beta kubernetes.io/region” | 数 ， 那 么 这 两 个 Pod 不 会 被 调度 到 相同 的 Node 上 

--hard-pod-affinity-symmetric-weight=1 | 表示 Pod 调度 规则 亲和力 的 权重 值 , 取 值 范围 为 0 一 100.RequiredDuringScheduling 
亲 和 性 是 非 对 称 的 ， 但 对 每 一 个 RequiredDuringScheduling 亲 和 性 都 存在 一 个 对 应 的 隐 
式 PreferredDuringScheduling 亲 和 性 规则 。 该 设置 表示 隐 式 PreferredDuringScheduling 
亲 和 性 规则 的 权重 值 ， 默 认为 1 

--kube-api-burst=100 发 送 到 API Server 的 每 秘 请 求 数量 ， 默 认为 100 

--kube-api-content-type="application‘vnd. | 发 送 到 API Server 的 请 求 内 容 类 型 

kubemetes.protobuf” 

—-kube-api-qps=50 与 API Server 通信 的 QPS (A, SKU 50 














--kubeconfig="” kubeconfig 配置 文件 路 径 ， 在 配置 文件 中 包括 Master 的 地 址 信息 及 必要 的 认证 信息 

--leader-elect[=false] 设置 为 true 表示 进行 leader 选举 ， 用 于 多 个 Master 组 件 的 高 可 用 部 署 

~-leader-elect-lease-duration=15s leader 选举 过 程 中 非 leader 等 待 选举 的 时 间 间 隔 , 默认 为 15 秒 , “4 leader-elect=true 
时 生效 











—leader-elect-renew-deadline=10s leader 选举 过 程 中 在 停止 leading 角色 之 前 再 次 renew 的 时 间 间 隔 ， 应 小 于 或 等 于 
leader-elect-lease-duration， 默 认为 10 秒 ， 当 leader-elect=true 时 生效 


—-leader-elect-retry-period=2s leader 选举 过 程 中 获取 leader 角色 和 renew 之 间 的 等 待 时 间 ， 默 认为 两 秒 ， 当 
leader-elect=true 时 生效 


API Server 的 URL 地 址 ， 设 置 后 不 再 使 用 kubeconfig 中 设置 的 值 
调度 策略 (scheduler policy) 配置 文件 的 路 径 
scheduler 监听 的 主机 端口 号 ， 默 认为 10251 


打开 性 能 分 析 ， 可 以 通过 <host>:<port>/debug/pprof 地址 查看 栈 、 线 程 等 系统 运行 
信息 

--scheduler-name="default-scheduler” 调度 器 名 称 ， 用 于 选择 哪些 Pod 将 被 该 调度 器 进行 处 理 ， 选 择 的 依据 是 Pod 的 
annotation 设置 ， 包 含 key='scheduler alpha kubernetes io/name 的 annotation 





5.kubelet 启 动 参数 
对 kubelet 启 动 参数 的 详细 说 明 如 表 2.7 所 示 。 
表 2.7 ”对 kubelet 启 动 参数 的 详细 说 明 


绑 定 主机 IP 地 址 ， 默 认为 0.0.0.0 表示 使 用 全 部 网 络 接口 
API Server 地 址 列表 ， 以 pport HARA, VUES 
为 每 个 容器 保存 的 性 能 指标 的 最 大 数量 ， 默 认为 100 


以 豆 号 分 隔 的 文件 列表 ， 使 用 第 1 个 存在 book-id 的 文件 
boot_id" 


本 地 Advisor MiBiiHMIIS. BUH 4194 


--cert-dir="/var/run/kubemetes TLS 证 书 所 在 的 目录 ， 默 认为 Ararimnkubermetes 。 如 果 设 置 了 --tls-cert-file 和 
--tls-private-key-file, WHR AH Rs 
为 pods 设置 的 root cgroup， 如 果 不 设置 ， 则 将 使 用 容器 运行 时 的 默认 设置 


--chaos 随机 产生 客户 端 错误 的 概率 ， 仅 用 于 测试 ， 默 认为 0， 即 不 产生 


集群 内 DNS 服务 的 瑟 地 址 
集群 内 DNS 服务 所 用 域名 


ce=0 
kubelet 配置 文件 的 路 径 或 目录 名 
设置 为 rue 表示 kubelet 将 会 根据 Node Spec PodCIDR 的 信 来 配置 cbr0 


--container-hints="/ete/cadvisor/contamer | 容器 hints 文件 所 在 的 全 路 径 
_hnts json 
--c 


ERAM, HNE Docker, kt, WKH docker 
将 kubelet 运行 在 容器 中 ， 仅 供 测试 使 用 ， 默 认为 false 
设置 为 tue 表示 启用 CPU CFS quota， 用 于 设置 容器 的 CPU 限制 


--docker-endpoint= Docker 服务 的 Endpoint 地 址 ， 默 认为 umix:///var/run/docker.sock 
‘wnix:///van'run/docker.sock 


Docker 容器 需要 使 用 的 环境 变量 key 列表 ， 以 到 号 分 了 
进入 Docker 容器 中 执行 盒 令 的 方式 ， 支 持 native、nsenter， 默 认为 mative 


-chani 


--cloud-provider="auto-detect” 云 服务 商 的 名 称 ， 默 认 将 自动 检测 ， 设 置 为 空 表示 无 云 服务 商 


BWA tue, RAMI Docker 容器 的 统计 信息 而 不 再 报告 其 他 统计 信息 


Docker 很 目录 的 全 路 径 ， 不 再 使 用 ， 将 通过 docker info 获取 该 信息 


--enable-controller-attach-detach[=true] 设置 为 tme 表示 启用 Attach/Detach Controller 进行 调度 到 该 Node 的 volume 的 
attach 与 detach 操作 ， 同 时 禁用 kubelet 执行 attach、detach 的 操作 


设置 为 rue 表示 启用 采集 自 定义 性 能 指标 


设置 为 tue 表示 提供 远程 访问 本 节点 容器 的 日 志 、 进 入 容器 执行 命令 等 相关 Rest 
服务 


设置 为 rue 表示 启用 CPU 负载 的 reader 


--enable-server[=tme] 启动 kubelet 上 的 http rest server, 此 server 提供 了 获取 本 节点 上 运行 的 Pod 列表 、 
Pod 状态 和 其 他 答 理 监控 相关 的 Rest 接口 


云 服务 商 的 配置 文件 路 生 
ws 





临时 允许 的 Event 记录 突 发 的 最 大 数量 ， 默 认为 10， 当 aventqps=0 时 生效 
设置 大 于 0 的 值 表示 限制 每 秒 能 创建 出 的 Event 数量 ， 设 置 为 0 表示 不 限制 
—event-storage-age-limit="default=0" 保存 Event 的 最 大 时 间 。 按 事件 类 型 以 key=value 的 格式 表示 ， 以 至 号 分 隔 ， 事 
件 类 型 包括 creation. oom 等 ,，“default” 表 示 记 有 事件 的 类 型 


--event-storage-event-limit="default=0" 保存 Event 的 最 大 数量 。 按 事件 类 型 以 key=value HK, LUBE, MHE 
类 型 包括 creation, oom 等 , “default” 表 示 所 有 事件 的 类 型 


MAÈ Pod Eviction 操作 的 一 组 硬 门限 设置 ， 例 如 可 用 内 存 <1Gi 


kubelet 在 触发 Pod Eviction 操作 之 前 等 待 的 最 长 时 间 ， 轩 认为 5 分 名 


—eviction-soft="" 艇 发 Pod Eviction 操作 的 一 组 软 门 限 设置 ， 例 如 可 用 内 存 <1.5Gi, 与 grace-period 
一 起 生效 ， 当 Pod 的 响应 时 间 超 过 grace-period 后 进行 揭发 
R Pod Eviction 操作 的 一 组 软 门限 等 待 时 间 设 置 ,例如 memory.available=lm30s 


--eviction-max-pod-grace-period=0 终止 Pod 操作 给 Pod HITR ALTRR MIATA). MAAE. 时 间 到 达 时 ， 将 触发 Pod 
Eviction 操作 。 默认 值 为 0 设置 为 负数 表示 使 用 Pod 中 指定 的 值 


设置 为 tne 表示 当 有 文件 镇 存在 时 kubelet 也 可 以 退出 
本 节点 上 NVIDIA GPU 的 数量 ， 目 前 仅 支 持 0 或 1， 冉 认为 0 


{E File Source 作为 Pod 源 的 情况 下 , kubelet 定期 重新 检查 文件 变化 的 时 间 间 隔 ， 
文件 发 生变 化 后 ，kubelet 重新 加 载 更 新 的 文件 内 容 
HEA FF Service Account ii #7 Fi FIEU] ISON key 
= 设置 haipin 模式 ,表示 kubelet 42 H hairpin NAT 的 方式 .该 模式 允许 后 端 Endpoint 
在 访问 其 本 身 Service 时 能 够 再 次 loadbalance 回 自身 、 可 选项 包括 promiscuous- 
bridge. hairpin-veth 和 none 
--healthz-bind-address=127.0.0.1 healthz IRS Mw A) IP 地 址 ， 默 认为 127.0.0.1， 设 置 为 00.00 表示 监 昕 全 部 IP 
地 址 
kubelet 允许 Pod 使 用 宿主 机 ipc namespace 的 列表 ， 以 逗号 分 隔 ， 默 认为 “*” 
kubelet 允许 Pod 使 用 宿主 机 network 的 列表 ， 以 逗号 分 隔 ， 默 认为 “+” 
kubelet 允许 Pod 使 用 宿主 机 pid namespace 的 列表 ， 以 去 号 分 隔 ， 默 认为 E” 


--http-check-frequency=20s HTTP URL Source 作为 Pod 源 的 情况 下 ，kubeiet 定期 检查 URL 返回 的 内 容 是 否 
发 生变 化 的 时 间 局 期 ， 作 用 同 file-check-frequency 参数 


镜像 垃 坟 回 收 上 限 ， 袜 盘 使 用 空间 达到 该 百分比 时 ， 秆 像 坊 圾 回收 将 持续 工作 
镜 人 垃圾 回收 下 限 ,， 磁盘 使 用 空间 在 达到 该 百分比 之 葡 , 镜像 垃圾 回收 将 不 启用 


发 送 到 API Server 的 等 黎 请 求 数量 ， 默 认为 10 


实验 性 功能 ， 用 于 kubelet 启动 时 自动 支持 aannel MARHA, KURA hle 





参数 名 和 取 值 示例 | 


-kubemetes.protobuf” 
~-kube-reserved= kubernetes 系统 预 留 的 资源 配置 , 以 一 组 ResourceName=ResourceQuantity 格式 去 
示 ， 例 如 cpu=200m,memory=150G。 目前 仅 支 持 CPU 和 内 存 的 设置 ， 详 见 http:// 
releases k8s.io/HEAD/docs/user-guide/compute-resources.md, UHF 
| -etae= | kubelet (VHA ock fH, Abba OOOO O 


--low-diskspace-threshold-mb=256 本 Node RERA Hy Sef], Hf MB. SEFE FAR, kubelet 将 拒绝 
创建 新 的 Pod， 默 认 值 为 256MB 


--machine-id-file="/etc’machine-id,/varli | 用 于 查找 machine-id 的 文件 列表 ， 使 用 找到 的 第 1 个 值 ， 默 认 从 /etc/machine-id, 
(var/lib/dbus/machine-id 文件 中 去 查找 


~-manifest-ul="" 为 HTTP URL Source 源 类 型 时 , kubelet 用 来 获取 Pod 定义 的 URL 地 址 , 此 URL 
返回 一 组 Pod 定义 


访问 menifest URL 地 址 时 使 用 的 HTTP 头 信息 ， 以 key-value 格式 表示 
--master-service-namespace="default” Master 服务 的 命名 空间 ， 默 认为 default 


续 表 
说 OA 
; 





kubelet 打开 的 最 大 文件 数量 ， 默 认为 1000 000 
belt 能 运行 的 最 大 Pod RLM, BUH 110 个 Pod 


--maximum-dead-contamers=240 在 本 Node 上 保留 的 已 停止 容器 的 最 大 数量 ， 由 于 停止 移 容 嚣 也 会 消耗 磁盘 空间 ,所 
以 超过 该 上 限 以 后 ，kubelet 会 自动 清理 已 停止 的 容器 以 释放 磁盘 宝 间 ， 默 认为 240 


--minimum-container-ttl-duration=lm0s 已 停止 的 容器 在 被 清理 之 前 的 最 小 存活 时 间 ， 例 如 300ms、10s 或 2h45m， 超 过 

_——— | 此 存活 时 间 的 容器 将 被 标记 为 可 被 GC IA, BRUCE 1 分 名 

不 再 使 用 的 镜像 在 被 清理 之 前 的 最 小 存活 时 间 ， 例 如 300ms、10s 或 2h45m， 超 
过 此 存活 时 间 的 镜像 被 标记 为 可 被 GC 清理 ， 默 认 值 为 两 分 钟 

自 定义 的 网 络 插件 的 名 字 , Pod 的 生命 周期 中 相关 的 一 些 事件 会 证 用 此 网 络 插件 
进行 处 理 ， 为 Alpha 测试 版 功能 


--network-plugin-dir="/usr/libexec/kuber | 扫描 网 络 插件 的 目录 ， 为 Alpha 测试 版 功能 


netes/kubelet-plugins/net/exec!” 


--node-ip="” 设置 本 Node f) IP 地 址 


--node-labels= kubelet 注册 本 Node #712 Wf) Labels, label 以 key=value 的 格式 表示 ， 多 个 label 


以 逗号 分 隔 ， 为 Alpha 测试 版 功能 
--node-status-update-frequency=10s kubelet f] Master 汇报 Node 状态 的 时 间 间 隔 ， 默 认 值 为 10 h. 45 controller- 
manager 的 一 node-monitor-erace-period 套数 共同 起 作用 


--non-masquerade-cidi="10.0.0.0/8” kubelet [A] i% IP Bk SpA IP Hh hh RSHI AHS ER IP Masquerade 技术 


参数 名 和 到 值 示例 
用 于 给 Pod 分 配 瑟 地址 的 CIDR 地 址 池 ， 仅 在 单机 模式 中 使 用 。 在 一 个 集群 中 ， 
kubelet 会 从 API Server 中 获取 CIDR 设置 


--pod-infra-container-image="gcr.io/ 用 于 Pod 内 网 络 命名 空间 共享 的 基础 pause 镜像 
google_containers'pause-amd64-3.0” 


该 kubelet 上 每 个 core 可 运行 的 Pod 数量 。 最 大 值 将 被 max-pods SHRM. K 
认 值 为 0 表示 不 做 限制 


设置 为 tue 表示 发 生 panics HAH IM. WAP MA 
根据 API Server 指定 的 CIDR WHE Node 的 CIDR 地 址 ， 如 果 register-node 或 
configure-cbr0 EA fale, MERTER. MUREX true 


将 本 Node 注册 到 API Server, UAH tue 


将 本 Node 状态 标记 为 schedulable, 12 HA false 表示 通知 Master 本 Node 不 可 进 


行 调 度 。 默 认 值 为 bue 


最 多 同时 拉 取 镜像 的 数量 ， 默 认 值 为 10 


在 Pod 创建 过 程 中 容器 的 镜像 可 能 需要 从 Regisby 中 拉 取 , 由 于 拉 取 镜像 的 过 程 中 
会 消耗 大 量 带 帘 ， 因此 可 能 需要 限 速 ,此 参数 与 regishy-burst 一 起 用 来 限制 每 秒 拉 
取 多 少 个 镜像 ， 默 认 不 限 速 ， 如 果 设 置 为 5， 则 表示 平均 每 秒 允 许 拉 取 5 个 镜像 
rkt 二 进 制 文件 的 路 径 , 不 指定 的 话 从 环境 变量 SPATH 中 查找 , --container-runtime 
=rkt HEX 

~-root-dir="var/lib/kubelet” 

--runonce=false 设置 为 tue 表示 创建 完 Pod 之 后 立即 退出 kubelet 进程 ， 与 --api-servers 和 
--enable-server S H JF 

~runtime-cgroup:="™" 

--runtime-request-timeout=2m0s 除了 长 时 间 运 行 的 request, 对 其 他 request 的 超时 时 间 设 置 ,包括 pull. logs. exec. 
attach 等 揉 作 。 当 超时 时 间 到 达 时 ， 请 求 会 被 杀 掉 ， 抛 出 一 个 错误 并 会 重 试 。 默 
认 值 为 两 分 钟 


--seccomp-profile-root="/var'lib/kubelet/s | seccomp 配置 文件 目录 ， 默 认为 /var/lib/kubelet/seccomp 
eccomp™ 


--serialize-image-pulls[=tmue] HFEA pull 镜像 。 建 议 Docker 低 于 <1.9 版 本 或 使 用 Aufs storage backend 时 
设置 为 hue， 详 见 issue #10959 


--storage-driver-buffer-duration=lm0s FER EAE S A fe ten FF fe AS Pf A, RAA 1 分 钟 





参数 名 和 取 值 示例 说 A 
—storage-driver-db="cadvisor” 后 端 存 储 的 数据 库 名 称 ， 默 认为 cadvisor 





后 端 存储 的 数据 库 连接 URL 地 址 ， 默 认为 localhost8086 
后 端 存储 的 数据 库 密码 ， 默 认为 root 
—storage-driver-secure[=false] 后 端 存储 的 数据 库 是 否 用 安全 连接 ， 默 认为 false 
—storage-driver-table="stats” 后 端 存储 的 数据 库 表 名 ， 默 认为 stats 
—storage-driver-user="root" 后 端 存储 的 数据 库 用 户 名 ， 默 认为 root 
—streaming-connection-idle-timeout= 在 容器 中 执行 命令 或 者 进行 端口 转发 的 过 程 中 会 产生 输入 、 输出 流 , 这 个 参数 用 
4n0m0s 来 控制 连接 空闲 超时 而 关闭 的 时 间 ， 如 果 设 置 为 “Sm”， 则 表示 连接 超过 5 分 钟 
没有 和 输入 、 输 出 的 情况 下 就 被 认为 是 空闲 的 ， 而 会 被 自动 关闭 。 默 认为 4 小 时 
—sync-frequency=1m0s 同步 运行 中 容器 的 配置 的 频率 ， 默 认为 1 分 钟 
—system-cgroups= kubelet 为 运行 非 kernel 进程 设置 的 cgroups 名 称 


—system-reserved= 系统 预 留 的 资源 配置 ， 以 一 组 ResourceName=ResourceQuantity 格式 表示 ， 例 如 
cpu=200m.memory=150G- 目 前 仅 支持 CPU 和 内 存 的 设置 , 详 见 http://releases.k8s. 
io/HEAD/docs/user-guide/compute-resources.md, UHE 


包含 x509 与 tls-cert-file 对 应 的 私 钥 文件 路 径 
一 volume-plugin-dir="/usr/libexec/kubern | 搜索 第 三 方 volume 插件 的 目录 ， 为 Alpha 测试 版 功能 
etes/kubelet-plugins/volume/exec/" 
—volume-stats-agg-period=1m0s kubelet 计算 所 有 Pod 和 volume 的 磁 益 使 用 情况 聚合 值 的 时 间 间 隔 ， 默 认为 1 分 
钟 。 设 置 为 0 表示 不 启用 该 计算 功能 














6.kube-proxy 启 动 参数 
kube-proxy 的 局 动 参数 详细 说明 见 表 2.8。 


表 2.8 kube-proxy 的 参数 表 


参数 名 和 取 值 示例 
--bind-address=0.0.0.0 kube-proxy 绑 定 主机 的 IP 地 址 ， 默 认为 0.0.0.0 表示 绑 定 所 有 IP 地 址 
--cleanup-iptables[=false] 设置 为 tme 表示 清除 iptables 规则 后 退出 
--cluster-cidr="" 集群 中 Pod 的 CIDR 地 址 范围 ， 用 于 桥接 集群 外 部 流量 到 内 部 。 用 于 公有 云 
环境 








--config-sync-period=15m0s 从 API Server 更 新 配置 的 时 间 问 隔 ， 默 认为 15 分 钟 ， 必 须 大 于 0 
--conntrack-max=0 跟踪 NAT 连接 的 最 大 数量 ， 默 认 值 为 0 表示 不 限制 
--conntrack-max-per-core=32768 跟踪 每 个 CPU core 的 NAT 连接 的 最 大 数量 ,默认 值 为 32768, 仅 当 conntrack- 
max 设置 为 0 时 生效 

--conntrack-tcp-timeout-established=24h0m0s | 建立 TCP 连接 的 超时 时 间 ， 默 认为 24 小 时 ， 设 置 为 0 表示 无 限制 














参数 名 和 取 值 示例 


说 A 





--healthz-bind-address=127.0.0.1 


healthz 服务 绑 定 主机 IP 地 址 ， 默 认为 127.0.0.1， 设 置 为 0.0.0.0 表示 使 用 所 
有 下 地 址 





--healthz-port=10249 


healthz 服务 监听 的 主机 端口 号 ， 默 认为 10249 





--hostname-override="" 


设置 本 Node 在 集群 中 的 主机 名 ， 不 设置 将 使 用 本 机 hostanme 








--iptables-masquerade-bit=14 


iptables masquerade 的 fwmark 位 设置 ， 有 效 范围 为 [0. 31] 





--iptables-sync-period=30s 


刷新 iptables 规则 的 时 间 间 隔 ， 例 如 Ss. Im, 2h22m, WRUH 30 秒 ， 必 须 大 
于 0 





--kube-api-burst=10 


发 送 到 API Server 的 每 秒 发 请 求 数量 ， 默 认为 10 





--kube-api-content-type="application/vnd.kub 


emetes.protobuf" 


发 送 到 API Server 的 请 求 内 容 类 型 





--kube-api-qps=5 


与 API Server 通信 的 QPS fi, RUA 5 





--kubeconfig="" 


kubeconfig 配置 文件 路 径 ， 在 配置 文件 中 包括 Master 地 址 信息 及 必要 的 认证 
信息 





--masquerade-all[=false] 


设置 为 true 表示 使 用 纯 iptables 代理 ， 所 有 网 络 包 都 将 做 SNAT 转换 





--master="" 


API Server 的 地 址 





--oom-score-adj=-999 


kube-proxy 进程 的 oom_score_adj 参数 值 ， 有 效 范围 为 -1000.1000] 





--proxy-mode= 


代理 模式 ， 可 选项 为 iptables BY userspace, BRU iptables, HAAR. “4 
操作 系统 kemel 版 本 或 iptables 版 本 不 够 新 时 ， 将 自动 降级 为 userspace 模式 





--proxy-port-range= 





进行 Service 代理 的 本 地 端口 号 范围 ， 格 式 为 begin-end， 含 两 端 ， 未 指定 则 
采用 随机 选择 的 系统 可 用 的 端口 号 





--udp-timeout=250ms 





保持 空闲 UDP 连接 的 时 间 , 例如 250ms, 2s, 默认 值 为 250ms， 必 须 大 于 0, 


仅 当 proxy-mode=userspace 时 生效 





2.1.7 “Kubernetes 集 和 群 网 络 配置 方案 





在 多 个 Node 组 成 的 Kubernetes 集 群 内 ， 踊 主机 的 容器 间 网 络 互 通 是 
Kubernetes 集 群 能 够 正常 工作 的 前 提 条 件 。Kubernetes 本 喘 并 不 会 对 路 主 
机 容器 网 络 进行 设置 ， 这 需要 额外 的 工具 来 实现 。 除 了 谷歌 公有 云 GCE 
平台 提供 的 网 络 设 置 ， 一 些 开 源 的 工具 包括 flannel、Open  vSwitch, 
Weave、Calico 等 都 能 够 实现 跨 主 机 的 容器 间 网 络 互 通 。 本 节 将 对 常用 
的 fannel、Open vSwitch 和 直接 路 由 三 种 配置 进行 详细 说 明 。 





1.flannel (7 m) 

flannel HE te 2% (Overlay Network) 模型 来 完成 对 网 络 的 打 
通 ， 本 节 对 flannel 的 安装 和 配置 进行 详细 说 明 。 

1) 安装 etcd 


由 于 flannel 使 用 etcd 作 为 数据 库 ， 所 以 需要 预先 安装 好 etcd， 详 见 
2.1.2 节 的 说 明 。 


2) 安装 flannel 


需要 在 每 台 Node 上 都 安装 flannel。flannel 软 件 的 下 载 地 址 为 
https://github.com/coreos/flannel/releases。 将 下 载 的 压缩 包 flannel- 
<version>-]linux-amd64.tar.gz 解 压 ， 把 二 进 制 文 件 flanneld 和 mk-docker- 
opts.sh 复 制 到 /usr/bin( 或 其 他 PATH 坏 境 变 量 中 的 目录 ) ， 即 可 完成 对 
flannel 的 安装 。 


3) 配置 flannel 


此 处 以 使 用 systemd 系 统 为 例 对 flanneld 服 务 进行 配置 。 编 辑 服 务 配 
置 文件 /usr/lib/systemd/system/flanneld.service: 


[Unit] 
Description=flanneld overlay address etcd agent 
After=network.target 


Before=docker.service 


[Service | 
Type=notify 
EnvironmentFile=/etc/sysconfig/flanneld 


ExecStart=/usr/bin/flanneld -etcd-endpoints=${FLANNEL_ET 


[Install] 
RequiredBy=docker.service 


WantedBy=multi-user. target 


编辑 配置 文件 /etc/sysconfig/flannel， 设 置 etcd 的 URL 地 址 : 


# flanneld configuration options 


# etcd url location. Point this to the server where etc 


FLANNEL_ETCD="http://192.168.18.3:2379" 


# etcd config key. This is the configuration key that f. 


# For address range assignment 


FLANNEL_ETCD_KEY="/coreos.com/network" 








XK 


在 启动 fanneld 服 务 之 前 ， 需 要 在 etcd 中 添加 一 条 网 络 配置 记录 ， 
个 配置 将 用 于 flanneld 分 配给 每 个 Docker 的 虚拟 IP 地 址 段 。 


# etcdctl set /coreos.com/network/config '{ "Network": ": 


4) HF flannel 78 tidockerOM tf, Pru R Docker kós GAB, 
则 停止 Docker 服 务 。 


5) 启动 flanneld 服 务 : 


# systemctl restart flanneld 


6) 设置 docker0 网 桥 的 IP 地 址 : 


# mk-docker-opts.sh -i 
# source /run/flannel/subnet.env 


# ifconfig dockerO ${FLANNEL_SUBNET } 


完成 后 确认 网 络 接 口 docker0 的 IP 地 址 属于 flannel0 的 子 网 : 


# ip addr 

flannel0: flags=4305<UP, POINTOPOINT, RUNNING, NOARP, MULTIC, 
inet 10.1.10.0 netmask 255.255.0.0 destination 

docker0: flags=4163<UP, BROADCAST, RUNNING, MULTICAST> mtu 
inet 10.1.10.1 netmask 255.255.255.0 broadcast 


7) 重新 启动 Docker 服 务 : 


# systemctl restart docker 


BEIRTE T flannel 7 ce 2S AW E o 


使 用 ping 命 令 验证 各 Node 上 docker0 之 间 的 相互 访问 。 例 如 在 
Node1 (docker0IP=10.1.10.1) 机 右上 ping Node2 的 docker0 (docker0‘s 
IP=10.1.30.1) ， 通 过 flannel 能 够 成 功 连 接 到 其 他 物理 机 的 Docker 网 络 : 


$ ping 10.1.30.1 

PING10.1.30.1 (10.1.30.1) 56(84) bytes of data. 

64 bytes from 10.1.30.1: icmp_seq=1 ttl=62 time=1.15 ms 
64 bytes from 10.1.30.1: icmp_seq=2 ttl=62 time=1.16 ms 


64 bytes from 10.1.30.1: icmp_seq=3 ttl=62 time=1.57 ms 


我 们 也 可 以 在 etcd 中 查看 到 flannel 设 置 的 flannel0 地 址 与 物理 机 IP 地 
址 的 对 应 规则 : 


# etcdctl 1s /coreos.com/network/subnets 
/coreos.com/network/subnets/10.1.10.0-24 
/coreos.com/network/subnets/10.1.20.0-24 


/coreos.com/network/subnets/10.1.30.0-24 


# etcdctl get /coreos.com/network/subnets/10.1.10.0-24 
{"PublicIP": "192.168.1.129"} 
# etcdctl get /coreos.com/network/subnets/10.1.20.0-24 
{"PublicIP": "192.168.1.130"} 


# etcdctl get /coreos.com/network/subnets/10.1.30.0-24 


{"PublicIP": "192.168.1.131"} 


2.Open vSwitch (虚拟 交换 机 ) 


以 两 个 Node 为 例 ， 目 标 网 络 拓扑 如 图 2.2 所 示 。 























Node1 Node2 
fiat 容器 2 
B~T 
[ . J 
dockerO 
| 172.17.43.1124 | 
IRE fë 4 
-全 | 一 ovs 











ping 172.17.43.71 








图 2.2 ”通过 Open vSwitch 打 通 网 络 


首先 ， 确 保 节 点 192.168.18.128 的 Docker0 采 用 172.17.43.0/24 网 段 ， 
而 192.168.18.131 的 Docker0 采 用 172.17.42.0/24 网 段 ， 对 应 参数 为 docker 
daemon 的 启动 参数 --bip 设 置 的 值 。 


Open vSwitch 的 安装 和 配置 方法 如 下 。 


1) 在 两 个 Node 上 安装 ovs 


# yum install openvswitch-2.4.0-1.x86_64.rpm 


禁止 selinux， 配 置 后 重启 Linux: 


# vi /etc/selinux/config 


SELINUX=disabled 





#4 Open vSwitch 的 服务 状态 ， 应 该 启动 两 个 进程 : ovsdb-server 与 


Ovs-vswitchd. 


# service openvswitch status 
ovsdb-server is running with pid 2429 


Ovs-vswitchd is running with pid 2439 


#14 Open vSwitch 的 相关 日 志 ， 确 认 没 有 异常 : 


# more /var/log/messages |grep openv 

Nov 2 03:12:52 docker128 openvswitch: Starting ovsdb-se 

Nov 2 03:12:52 docker128 openvswitch: Configuring Open ' 

Nov 2 03:12:52 docker128 kernel: openvswitch: Open vSwi 
2 


Nov 03:12:52 docker128 openvswitch: Inserting openvsw 


注意 上 述 操作 需要 在 两 个 节点 机 器 上 分 别 执行 完成 。 


2) 创建 网 酉 和 GRE 隧 道 








接 下 来 需要 在 每 个 Node 上 建立 ovs 的 网 桥 br0， 然 后 在 网 桥 上 创建 一 
个 GRE 隧 道 连 接 对 端 网 酉 ， 最 后 把 ovs 的 网 桥 br0 作 为 一 个 端口 连接 到 
docker0 这 个 Linux 网 桥 上 《可 以 认为 是 交换 机 互联 ) ， 这 样 一 来 ， 两 个 
节点 机 器 上 的 docker0 网 段 就 能 互通 了 。 


下 面 以 节点 机 器 192.168.18.131 为 例 ， 具 体 的 操作 步骤 如 下 。 


(1) 创建 ovs 网 桥 : 
# ovs-vsctl add-br bro 
(2) 创建 GRE 隧 道 连接 对 端 ，remote_ip 为 对 端 eth0 的 网 卡 地 址 : 
# ovs-vsctl add-port brO grei -- set interface grei type 
(3) YsiibrOZ) AHhdockerO, (EAA aril I WOVSiiAtunnel: 
# brctl addif docker® bro 
(4) 启动 br0 与 docker0 网 桥 : 


# ip link set dev brO up 


# ip link set dev docker®O up 


(5) 添加 路 由 规则 。 由 于 192.168.18.128 与 192.168.18.131 的 
docker0 网 段 分 别 为 172.17.43.0/24 与 172.17.42.0/24， 这 两 个 网 段 的 路 由 
都 需要 经 过 本 机 的 docker0 网 桥 路 由 ， 其 中 一 个 24 网 段 是 通过 OVS 的 
GRE 隧 道 到 达 对 端的 ， 因 此 需要 在 每 个 Node 上 添加 通过 docker0 网 桥 转 
发 的 172.17.0.0/16 段 的 路 由 规则 : 





# ip route add 172.17.0.0/16 dev docker®O 


(6) 清空 Docker 目 带 的 Iptables 规 则 及 Linux 的 规则 ， 后 者 存在 拒绝 
icmp 报 文通 过 防火 墙 的 规则 ;: 


# iptables -t nat -F; iptables -F 


在 192.168.18.131 上 完成 上 述 步 又 后 ， 在 192.168.18.128 节 点 执行 同 
样 的 操作 ， 注 意 ，GRE 隧 道里 的 卫 地 址 要 改 为 对 端 节点 
(192.168.18.131) 的 耳 地 址 。 





配置 完成 后 ，192.168.18.131 的 IP 地 址 、docker0 的 IP 地 址 及 路 由 等 





+ 


ip addr 
1: lo: <LOOPBACK, UP, LOWER_UP> mtu 65536 qdisc noqueue sti 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:0 
inet 127.0.0.1/8 scope host lo 
valid_lft forever preferred_lft forever 
2: ethO: <BROADCAST, MULTICAST, UP, LOWER_UP> mtu 1500 qdis: 
link/ether 00:0c:29:55:5e:c3 brd ff: ff: ff: ff: ff: fF 
inet 192.168.18.131/24 brd 192.168.18.255 scope glob 
valid_lft 1369sec preferred_lft 1369sec 
3: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop 
link/ether a6:15:c3:25:cf:33 brd ff: ff: ff: ff: ff: fF 
4: brO: <BROADCAST,MULTICAST, UP, LOWER_UP> mtu 1500 qdisc 
link/ether 92:8d:d0:a4:ca:45 brd ff: ff: ff: ff: ff: fF 
5: docker0: <BROADCAST, MULTICAST, UP, LOWER_UP> mtu 1500 q 
link/ether 02:42:44:8d:62:11 brd ff:ff:ff:ff:ff:ff 
inet 172.17.42.1/24 scope global dockerg 


valid_lft forever preferred_lft forever 





同样 ，192.168.18.128 节 点 的 重要 信息 如 下 : 


# ip addr 
1: lo: <LOOPBACK, UP, LOWER_UP> mtu 65536 qdisc noqueue sti 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:0 
inet 127.0.0.1/8 scope host lo 
valid_lft forever preferred_lft forever 
2: ethO: <BROADCAST, MULTICAST, UP, LOWER_UP> mtu 1500 qdis: 
link/ether 00:0c:29:e8:02:c7 brd ff: ff: ff: ff: ff: fF 
inet 192.168.18.128/24 brd 192.168.18.255 scope glob 
valid_lft 1356sec preferred_lft 1356sec 
3: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop 
link/ether fa:6c:89:a2:f2:01 brd ff: ff: ff: ff: ff: fF 
4: brO: <BROADCAST, MULTICAST, UP, LOWER_UP> mtu 1500 qdisc 
link/ether ba:89:14:e0:7f:43 brd ff: ff: ff: ff: ff: fF 
5: docker0: <BROADCAST, MULTICAST, UP, LOWER_UP> mtu 1500 q 
link/ether 02:42:63:a8:14:d5 brd ff:ff:ff:ff:ff:ff 
inet 172.17.43.1/24 scope global dockerg 


valid_lft forever preferred_lft forever 


3) 两 个 Node 上 容器 之 间 的 互通 测试 


首先 ， 在 192.168.18.128 节 点 上 ping192.168.18.131 上 的 docker0 地 
hE: 172.17.42.1， 验 证 网 络 互 通 性 : 


# ping 172.17.42.1 
PING 172.17.42.1 (172.17.42.1) 56(84) bytes of data. 


64 bytes from 172.17.42. icmp_seq=1 


64 bytes from 172.17.42. icmp_seq=2 
64 bytes from 172.17.42. icmp_seq=3 
64 bytes from 172.17.42. icmp_seq=4 


64 bytes from 172.17.42. icmp_seq=5 


BP BP RB BE B B 


64 bytes from 172.17.42. icmp_seq=6 


ttl=64 time=1.57 m 
ttl=64 time=0.966 | 
ttl=64 time=1.01 m 
ttl=64 time=1.00 m 
ttl=64 time=1.22 m 


ttl=64 time=0.996 | 








FARINE tsharkjl LL AK a7 EE H o 


Ao E 


192.168.18.128 节 点 上 监听 br0 上 是 否 有 GRE 报 文 ， 执 行 下 面 的 命令 ， 我 


们 发 现 br0 上 并 没有 GRE 报 文 : 


# tshark -i brO -R ip proto GRE 


tshark: -R without -2 is deprecated. 


For single-pass fil 


Running as user "root" and group "root". This could be di 


Capturing on 'bro' 


AC 





而 在 eth0 上 抓 包 ， 则 发 现 了 GRE 封 装 的 ping 包 报 文通 过 ， 说 明 GRE 


是 在 承载 网 的 物理 网 上 完成 的 封包 过 程 : 


# tshark -i etho -R ip proto GRE 


tshark: -R without -2 is deprecated. 


For single-pass fil 


Running as user "root" and group "root". This could be di 


Capturing on ‘etho' 


1 0.000000 172.17.43.1 -> 172.17.42.1 ICMP 136 Ech 


2 0.000892 172.17.42.1 -> 172.17.43.1 ICMP 136 Ech 


2 3 1.002014 172.17.43.1 -> 172.17.42.1 ICMP 136 Ei 


4 1.002916 


4 5 


至 此 ， 基 于 OVS 的 网 络 搭建 成 功 ， 由 于 GRE 是 点 对 点 隧道 通信 方 
式 ， 所 以 如 果 有 多 个 Node， 则 需要 建立 Nx (N-1) 条 GRE 隧 道 ， 即 所 有 
Node 组 成 一 个 网 状 的 网 络 ， 


3. 直 接 路 由 


通过 在 每 个 Node 上 添加 到 其 他 Node 上 docker0 的 静态 路 由 规则 ， 就 
可 以 将 不 同 物理 机 的 docker0 网 桥 互 联 互通 。 图 2.3 摘 述 了 在 两 个 Node 之 


2.004101 172.17.43.1 


172.17.42.1 


-> 172 


实现 全 网 互通 。 





-> 172.17.43.1 


17.42.11 




























































































间 打 通 网 络 的 情况 。 
Node1 Node2 
fi > iin 
f Pod 1 \ / Pod 2 
容器 1 | | 容器 2 容器 1 | | 容器 2 
共享 网 络 共享 网 络 
空间 © |] 空间 
E> | 
- \ 
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图 2.3 ”以 直接 路 由 方式 实现 Pod 到 Pod 的 通信 














使 用 这 种 方案 ， 只 需要 在 每 个 Node 的 路 由 表 中 增加 到 对 方 docker0 
的 静态 路 由 转发 规则 。 


例如 Pod1 所 在 docker0 网 桥 的 IP 子 网 是 10.1.10.0，Node 地 址 为 
192.168.1.128; 而 Pod2 所 在 docker0 网 桥 的 人 P 子 网 是 10.1.20.0，Node 地 址 
为 192.168.1.129。 


在 Node1 上 用 route ” add 命令 增加 一 条 到 Node2 上 docker0 的 静态 路 由 


route add -net 10.1.20.0 netmask 255.255.255.0 gw 192.16 


同样 ， 在 Node2 上 增加 一 条 到 Nodel 上 docker0 的 静态 路 由 规则 


route add -net 10.1.10.0 netmask 255.255.255.0 gw 192.16 


在 Nodel1 上 通过 ping 命 令 验 证 到 Node2 上 docker0 的 网 络 连通 性 。 这 
里 10.1.20.1 为 Node2 上 docker0 网 桥 自 身 的 IP 地 址 。 


$ ping 10.1.20.1 

PING10.1.20.1 (10.1.20.1) 56(84) bytes of data. 

64 bytes from 10.1.20.1: icmp_seq=1 ttl=62 time=1.15 ms 
64 bytes from 10.1.20.1: icmp_seq=2 ttl=62 time=1.16 ms 


64 bytes from 10.1.20.1: icmp_seq=3 ttl=62 time=1.57 ms 





可 以 看 到 ， 路 由 转发 规则 生效 ，Nodel 可 以 直接 访问 到 Node2 上 的 
docker0 网 桥 ， 进 一 步 也 可 以 访问 到 属于 docker0 网 段 的 容器 应 用 了 。 


不 过 ， 集 群 中 机 器 的 数量 通常 可 能 很 多 。 假 设 有 100 台 服务 器 ， 那 
么 就 需要 在 每 台 服 务 器 上 手工 添加 a 到 另外 99 台 服务 器 docker0 的 路 由 规 
则 。 为 了 减少 手工 操作 ， 可 以 使 用 Quagga 软 件 来 实现 路 由 规则 的 动态 添 
加 。Quagga 软 件 的 主页 为 http:/www.quagga.net。 


除了 在 每 台 服 务 器 上 安装 Quagga 软 件 并 启动 ， 还 可 以 使 用 Quagga 
容 右 来 运行 (例如 index.alauda.cn/georce/router) 。 在 每 台 Node 上 下 载 该 
Docker 镜 像 : 


$ docker pull index.alauda.cn/georce/router 





在 运行 Quagga 容 器 之 前 ， 需 要 确保 每 个 Node 上 docker0 网 桥 的 子 网 
地 址 不 能 重 登 ， 也 不 能 与 物理 机 所 在 的 网 络 重 登 ， 这 需要 网 络 管理 员 的 
仔细 规划 。 


下 面 以 3 个 Node 为 例 ， 每 台 Node 的 docker0 网 桥 的 地 址 如 下 “前 提 是 
Node 物 理 机 的 下 地 址 不 是 10.1.X.X 地 址 段 ) : 


Node 1: # ifconfig dockerg 10.1.10.1/24 
Node 2: # ifconfig dockerg 10.1.20.1/24 
Node 3: # ifconfig dockerg 10.1.30.1/24 


然后 在 每 个 Node 上 启动 Quagga 容 器 。 需 要 说 明 的 是 ，Quagga 需 要 
以 --privileged 特 权 模 式 运 行 ， 并 且 指 定 --net=host， 表 示 直 接 使 用 物理 机 
的 网 络 : 


$ docker run -itd --name=router --privileged --net=host 


司 动 成 功 后 ，Quagga 会 相互 学 习 来 完成 到 其 他 机 器 的 docker0 路 由 


规则 的 添加 。 


一 段 时 间 后 ， 在 Node1 上 使 用 route-n 命 令 


来 查看 路 由 表 ， 可 以 看 到 


Quagga 目 动 添加 了 两 条 到 Node2 和 到 Node3 上 docker0 的 路 由 规则 。 


# route -n 


Kernel IP routing table 


Destination Gateway 
0.0.0.0 192.168.1.128 
10.1.10.0 0.0.0.0 
10.1.20.0 192.168.1.12 
10.1.30.0 192.168.1.13 


Genmask Flags 
0.0.0.0 UG 
255.255.255.0 U 

9 255.255.255.0 UG 

© 255.255.255.0 UG 


在 Node2 上 查看 路 由 表 ， 可 以 看 到 自动 添加 了 两 条 到 Nodel 和 Node3 


上 docker0 的 路 由 规则 。 


# route -n 


Kernel IP routing table 


Destination Gateway 
0.0.0.0 192.168.1.129 
10.1.20.0 0.0.0.0 
10.1.10.0 192.168.1.128 
10.1.30.0 192.168.1.130 


Genmask Flags Me 
0.0.0.0 UG 0 
255.255.255.0 U 0 


255.255.255.0 UG 20 
255.255.255.0 UG 20 





至 此 ， 所 有 Node 上 的 docker0 都 可 以 互联 互通 了 。 


2.2 ”kubectl 命 令 行 工 具 用 法 详解 


kubectl 作 为 客户 端 CLI 工 具 ， 可 以 让 用 户 通 过 命令 行 的 方式 对 
Kubernetes 和 集群 进行 操作 。 本 节 对 kubectl 的 子 命令 和 用 法 进行 详细 说 
HA 


2.2.1 kubect 用 法 概述 


kubectl 命 令 行 的 语法 如 下 : 


$ kubectl [command] [TYPE] [NAME] [flags] 


HH, command. TYPE. NAME, flags unk . 


(1) command: 子 命令 ， 用 于 操作 Kubernetes 集 群 资源 对 象 的 命 
令 ， 例 如 create、delete、describe、get、apply 等 。 


(2) TYPE: 资源 对 象 的 类 型 ， 区 分 大 小 写 ， 能 以 单数 形式 、 复 数 
形式 或 者 简写 形式 表示 。 例 如 以 下 3 种 TYPE 是 等 价 的 。 


$ kubectl get pod pod1 
$ kubectl get pods pod1 
$ kubectl get po pod1 


(3) NAME: 资源 对 象 的 名 称 ， 区 分 大 小 写 。 如 果 不 指定 名 称 ， 
则 系统 将 返回 属于 TYPE 的 全 部 对 象 的 列表 ， 例 如 $kubectl get pods 将 返 
回 所 有 Pod 的 列表 。 


(4) flags: kubectl 子 命令 的 可 选 参数 ， 例 如 使 用 “-s” 指 定 apiserver 
的 URL 地 址 而 不 用 默认 值 。 


kubectl 可 操作 的 资源 对 象 类 型 如 表 2.9 所 示 。 


表 2.9 ”kubectl 可 操作 的 资源 对 象 类 型 


资源 对 象 的 名 称 





componentstatuses 





daemonsets 





deployments 





events 





endpoints 





horizontalpodautoscalers 





ingresses 





jobs 





limitranges 





nodes 





namespaces 





pods 





persistentvolumes 





persistentvolumeclaims 





resourcequotas 





replicationcontrollers 





secrets 





serviceaccounts 











services 


在 一 个 命令 行 中 也 可 以 同时 对 多 个 资源 对 象 进行 操作 ， 以 多 个 
TYPE 和 NAME 的 组 合 表 示 ， 示 例如 下 。 


。 获取 多 个 Pod 的 信息 : 
$ kubectl get pods pod1 pod2 
。 获取 多 种 对 象 的 信息 : 
$ kubectl get pod/pod1 rc/rci 
。 同时 应 用 多 个 yaml 文 件 ， 以 多 个 -f file 参 数 表示 : 


$ kubectl get pod -f podi.yaml -f pod2.yaml 


$ kubectl create -f podi.yaml -f rci.yaml -f Service1.yal 


2.2.2 kubectl (fit 


kubectlH TMS ae = ea pag ei 
资源 对 象 的 创建 、 删 除 、 


包括 资 


令 详 解 


查看 、 


令 如 表 2.10 所 示 。 


annotate 


表 2.10 kubectl Ar 


kubectl annotate [--overwrite] (-f FILENAME | TYPE NAME) 


KEY_1=VAL_1 .. KEY_N=VAL_N [-—resource-version=version] [flags] 


修改 、 配 置 、 


令 详解 


添加 或 更 新 资源 对 象 的 annotation 
信息 





api-Vefsions 


kubectl api-versions [flags] 


kubectl apply -f FILENAME [flags] 


kubectl attach POD -c CONTAINER [flags] 
kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) 
[--min=MINPODS] —max=MAXPODS [--cpu-percent=CPU] [flags] 


kubectl cluster-info [flags] 
kubectl cluster-info [command] 
kubectl completion SHELL [flags] 


列 出 当前 系统 支持 的 API 版 本 列表 ， 
格式 为 “ 
从 配置 文件 或 stdin 中 对 资源 对 象 进 
行 配置 更 新 

附着 到 一 个 正在 运行 的 容器 上 

对 Deployment、ReplicaSet 或 
ReplicationController 进行 水 平 自动 
扩 缩 容 的 设置 

显示 集群 信息 


group/version” 


输出 shell 命令 的 执行 结果 码 (bash 
或 zsh) 





kubectl config SUBCOMMAND [flags] 
kubectl config [command] 
kubectl convert -f FILENAME [flags] 


修改 kubeconfig 文件 


转换 配置 文件 为 不 同 的 API 版 本 





kubectl cordon NODE [flags] 


kubectl create -f FILENAME [flags] 

kubectl create [command] 

kubectl delete ([-f FILENAME] | TYPE [(NAME | -1 label | --all)]) 
[flags] 


将 Node 标记 为 unschedulable, 即 “ 隔 
离 ” 出 集群 调度 范围 
从 配置 文件 或 stdin 中 创建 资源 对 象 


根据 配置 文件 、stdin、 资 源 名 称 或 
label selector 删除 资源 对 象 





kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | /NAME | 
-1 label]) [flags] 
kubectl drain NODE [flags] 


kubectl edit (RESOURCE/NAME | -f FILENAME) [flags] 





描述 一 个 或 多 个 资源 对 象 的 详细 信 
息 

首先 将 Node 设置 为 unschedulable， 
然后 删除 该 Node 上 运行 的 所 有 了 Pod， 
但 不 会 删除 不 由 apiserver 管理 的 Pod 
编辑 资源 对 和 象 的 属性 ， 在 线 更 新 





。 详 细 的 子 命 


续 表 
[exec | kubect exec POD [-e CONTAINER] COMMAND [args..J(fae:) | 执行 一 个 容器 中 的 命令 | 
TT 


kubectl expose (-f FILENAME | TYPE NAME) [--port=port] | 将 已 经 存在 的 一 个 RC., Serice, 
[--protocol=TCPIUDP] [--target-port=number-or-name] [--name=name] | Deployment 或 Pod 且 露 为 一 个 新 的 
[--external-ip=external-ip-of-service] [--type=type] [flags] Service 

kubectl get [(-o|--output=)json!yaml|widelgo-template=..|go-template- | 显示 一 个 或 多 个 资源 对 象 的 概要 信 
file=...{jsonpath=...|jsonpath-file=...] (TYPE [NAME | -l label] | TYPE/ | & 

NAME ...) [flags] 

kubectl label [--overwnte] (-f FILENAME | TYPE NAME) 设置 或 更 新 资源 对 象 的 labels 
KEY_1=VAL_1 ... KEY_N=VAL_N [--resource-version=version] [flags] 


[oss | Anbectiogs -A EP] POD [re CONTAINER] [fae] =| NTO RMS | 

| namespace | kubectl namespace [namespace] [flag] | Ti kubectl config set-context tft | 

kubectl patch (-f FILENAME | TYPE NAME) -p PATCH [flags] 以 merge 形式 对 资源 对 象 的 部 分 字 
段 的 值 进行 修改 


[..[LOCAL_PORT_N-JREMOTE_PORT_N] [flags] 端 日 号 ， 通 常用 于 测试 工作 
i 
[--www- wa [--api-prefix=prefix] [flags] 
rolling-update | kubectl rolling-update OLD_CONTROLLER_NAME ([NEW_ | WRC 进行 滚动 升级 
CONTROLLER_NAME] --image=NEW_CONTAINER_IMAGE | 
-f NEW_CONTROLLER_SPEC) [flags] 
kubectl rollout SUBCOMMAND [flags] 对 Deployment 进行 管理 ， 可 用 操作 
kubectl rollout [command] 包括 : history. pause, resume. undo. 
status 
kubectl nn NAME --image=image [--env="key=value”] [--port=port] | 基于 一 个 镜 在 Kubemetes 集群 上 启 
[-+eplicas=replicas] [—dry-run=bool] [--overrides=inline-json] | 动 一 个 Deployment 
[--command] -- [COMMAND] [args...] [flags] 


kubectl scale [--resource-version=version] [-—current-replicas=count] | 3° 2%. 44% — 4 Deployment . 
--replicas=COUNT (-f FILENAME | TYPE NAME) [flags] ReplicaSet .RC 或 Job 中 Pod 的 数量 


kubectl set SUBCOMMAND [flags] 设置 资源 对 象 的 某 个 特定 信息 ， 目 

kubectl set [command] 前 仅 支 持 禾 改 容器 的 镜像 

kubectl taint NODE NAME KEY_1=VAL 1:TAINT EFFECT_1 ... | 设置 Node 的 taint 信息 ， 用 于 将 特 

KEY_N=VAL_N:TAINT_EFFECT_N [flags] 定 的 Pod 调度 到 特定 的 Node 的 操 
作 ， 为 — 版 本 功能 





kubectl 命 令 行 的 公 


2.2.3 ”kubectl 参 数列 表 


共 启 动 参数 如 表 2.11 所 示 。 


表 2.11 kubectl 命 令 行 公共 参数 


参数 名 和 取 值 示例 





--alsologtostderr[=false] 


设置 为 true 表示 将 日 志 输出 到 文件 的 同时 输出 到 stderr 





--as="" 


设置 本 次 操作 的 用 户 名 





--certificate-authority="" 


用 于 CA 授权 的 cert 文件 路 径 





--client-certificate="" 


用 于 TLS 的 客户 端 证 书 文件 路 径 





--client-key="" 


用 于 TLS 的 客户 端 key 文件 路 径 





--cluster="" 


设置 要 使 用 的 kubeconfig 中 的 cluster 名 





--context="" 





--insecure-skip-tls-verify[=false] 


设置 要 使 用 的 kubeconfig 中 的 context 名 
设置 为 true 表示 跳 过 TLS 安全 验证 模式 ， 将 使 得 HTTPS 连接 不 安全 








--kubeconfig="" 


kubeconfig 配置 文件 路 径 , 在 配置 文件 中 包括 Master 地 址 信息 及 必要 的 认证 信息 





--log-backtrace-at=:0 
--log-dir="" 


--log-flush-frequency=5s 


记录 日 志 每 到 “file: 行 号 ”时 打印 一 次 stack trace 
日 志文 件 路 径 
设置 flush 日 志文 件 的 时 间 间 隔 





--logtostderr[=true] 


设置 为 tue 表示 将 日 志 输 出 到 stderr， 不 输出 到 日 志文 件 





--match-server-version[=false] 


设置 为 true 表示 客户 端 版 本 号 需要 与 服务 端 一 至 





--namespace="" 


设置 本 次 操作 所 在 的 namespace 





--password="" 


设置 apiserver 的 basic authentication 的 密码 





-S, --server="" 


设置 apiserver 的 URL Hiht, BRU localhost:8080 





--stderrthreshold=2 


在 该 threshold 级 别 之 上 的 日 志 将 输出 到 stderr 





--token="" 


设置 访问 apiserver 的 安全 token 





--user="" 


--username= 


指定 kubeconfig 用 户 名 
设置 apiserver 的 basic authentication 的 用 户 名 





--v=0 


glog 日 志 级 别 





--vmodule= 


每 个 子 命令 (如 create、delete、get 等 ) 3 
通过 $kubectl[command]--help 命 令 进 行 查 看 。 








glog 基于 模块 的 详细 日 志 级 别 


还 有 特定 的 flags 参 数 ， 可 以 


2.2.4 kubect 输 出 格式 

kubectl 命 令 可 以 用 多 种 格式 对 结果 进行 显示 ， 输 出 的 格式 通过 -o 参 
数 指定 

$ kubectl [command] [TYPE] [NAME] -o=<output_format> 


根据 不 同 子 命令 的 输出 结果 ， 可 选 的 输出 格式 如 表 2.12 所 示 。 
表 2.12 ”kubect 命 令 输 出 格式 列表 


输出 格式 





-o=custom-columns=<spec> 根据 自 定 义 列 名 进行 输出 ， 以 逗号 分 隔 
-o=custom-columns-file=<filename> 从 文件 中 获取 自 定义 列 名 进行 输出 
-0=json 以 JSON 格式 显示 结果 











-0=jsonpath=<template> 输出 jsonpath 表达 式 定义 的 字段 信息 
-0=jsonpath-file=<filename> 输出 jsonpath 表达 式 定义 的 字段 信息 ， 来 源 于 文件 
-o=name 仅 输出 资源 对 象 的 名 称 

-o=wide 输出 额外 信息 。 对 于 Pod， 将 输出 Pod 所 在 的 Node 名 
-o=yaml 以 yaml 格式 显示 结果 


























党 用 的 输出 格式 示例 如 下 。 
(1) 显示 Pod 的 更 多 信息 : 


$ kubectl get pod <pod-name> -0 wide 


(2) 以 yaml 格 式 显 示 Pod 的 详细 信息 : 


$ kubectl get pod <pod-name> -0 yaml 


(3) 以 目 定义 列 名 显示 Pod 的 信息 : 


$ kubectl get pod <pod-name> -o=custom-columns=NAME: .meti 


(4) 基于 文件 的 目 定 义 列 名 输出 : 


$ kubectl get pods <pod-name> -o=custom-columns-file=tem 


template.txt 文 件 的 内 容 为 : 





NAME RSRC 
metadata.name metadata.resourceVersion 
输出 结果 为 : 
NAME RSRC 
pod-name 52305 
另外 ， 还 可 以 将 输出 结果 按 某 个 字段 排序 ， 通 过 --sort-by 参 数 以 


jsonpath 表 达 式 进行 指定 
$ kubectl [command] [TYPE] [NAME] --sort-by=<jsonpath_ex 


例如 ， 按 照 名 字 进 行 排序 : 


$ kubectl get pods --sort-by=.metadata.name 


2.2.5 ”kubectl 操 作 示 例 


本 节 对 一 些 常用 的 kubectl 操 作 进 行 示 例 。 


1. 创 建 资源 对 象 
根据 yaml 配 置 文件 一 次 性 创建 service 和 rc: 


$ kubectl create -f my-service.yaml -f my-rc.yaml 


根据 <directory> 目 录 下 所 有 .yaml、.yml、.json 文 件 的 定义 进行 创建 
操作 : 


$ kubectl create -f <directory> 


2. 查 看 资源 对 象 
查看 所 有 Pod 列 表 : 


$ kubectl get pods 


查看 rc 和 service 列 表 : 


$ kubectl get rc,service 


3. 摘 述 资源 对 象 
显示 Node 的 详 ais i: 


$ kubectl describe nodes <node-name> 


显示 Pod 的 详细 信息 : 
$ kubectl describe pods/<pod-name> 
显示 由 RC 管理 的 Pod 的 信息 : 


$ kubectl describe pods <rc-name> 


4. 删 除 资 源 对 象 
基于 pod.yaml 定 义 的 名 称 删除 Pod: 

$ kubectl delete -f pod.yaml 
删除 所 有 包含 某 个 label 的 Pod 和 service: 


$ kubectl delete pods,services -1 name=<label-name> 


删除 所 有 Pod: 


$ kubectl delete pods --all 


5. 执 行 容器 的 命令 
执行 Pod 的 date 命 令 ， 默 认 使 用 Pod 中 的 第 1 个 容器 执行 : 
$ kubectl exec <pod-name> date 

虽 定 Pod 中 某 个 容器 执行 date 命 令 


$ kubectl exec <pod-name> -c <container-name> date 





通过 bash 获 得 Pod 中 某 个 容器 的 TTY， 相 当 于 登录 容器 : 


$ kubectl exec -ti <pod-name> -c <container-name> /bin/bash 
6. 查 看 容器 的 日 志 

查看 容 占 输出 到 stdout 的 日 志 : 

$ kubectl logs <pod-name> 


跟踪 查看 容器 的 Elie © 相当 于 tail -f fit ~ 令 的 结 


$ kubectl logs -f <pod-name> -c <container-name> 


2.3 ”Guestbook 示 例 : Hello World 


在 对 Kubernetes 的 容器 应 用 进行 详细 说 明之 前 ， 让 我 们 先 通 过 一 个 
由 3 个 微服 务 组 成 的 留言 板 (Guestbook) 系统 的 搭建 ， 对 Kubernetes 对 
容器 应 用 的 基本 操作 和 用 法 进行 初步 介绍 。 本 章 后 面 的 章节 将 基于 该 案 
例 和 其 他 示例 ， 进 一 步 深入 Pod、RC、Service 等 核心 对 象 的 用 法 和 技 
巧 ， 对 Kubernetes 的 应 用 管理 进行 全 面 讲解 。 





Guestbook 留 言 板 系统 将 通过 Pod、RC、Service 等 资源 对 象 搭建 完 
成 ， 成 功 启动 后 在 网 页 中 显示 一 条 “Hello World” 留 言 。 其 系统 架构 是 一 
个 基于 PHP+Redis 的 分 布 式 Web 应 用 ， 前 器 PHP Web 网 站 通过 访问 后 端 
的 Redis 来 完成 用 户 留 言 的 查询 和 添加 等 功能 。 同 时 Redis 以 Master+Slave 
的 模式 进行 部 署 ， 实 现 数据 的 读 写 分 离 能 力 。 








留言 板 系统 的 部 署 架 构 如 图 2.4 所 示 。Web 层 是 一 个 基于 PHP 页 面 的 
Apache 服 务 ， 启 动 3 个 实例 组 成 集群 ， 为 客户 端 ( 例 如 浏览 器 对 网 站 
的 访问 提供 负载 均衡 。Redis Master 启 动 1 个 实例 用 于 写 操 作 (添加 留 
言 》，RedisSlave 启 动 两 个 实例 用 于 读 操 作 ( 读 取 留 言 )。RedisMaster 
与 Slave 的 数据 同步 由 Redis 具 备 的 数据 同步 机 制 完 成 。 








redis-master 





redis-slave 








图 2.4 ”留言 板 的 系统 部 署 染 构图 


在 本 例 中 将 要 用 到 3 个 Docker 镜 像 ， 下 载 地 址 为 
https://hub.docker.com/u/kubeguide/. 


e redis-master: 用 于 前 端 Web 应 用 进行 “ 写 ” 留 言 操作 的 Redis 服 务 ， 其 
中 已 经 保存 了 一 条 内 容 为 “Hello World! ”的 留言 。 

e guestbook-redis-slave: 用 于 前 端 Web 应 用 进行 “ 读 ” 留 言 操作 的 Redis 
服务 ， 并 与 Redis-Master 的 数据 保持 同步 。 

e guestbook-php-frontend: PHP Web 服务 ， 在 网 页 上 展示 留言 的 内 
容 ， 也 提供 一 个 文本 输入 框 供 访客 添加 留言 。 





如 图 2.5 所 示 为 Hello World 案 例 所 采用 的 Kubernetes 部 署 架 构 ， 这 里 
Master 与 Node 的 服务 处 于 同一 个 虚拟 机 中 。 通 过 创建 redis-master 服 务 、 
redis-slave 服 务 和 php-frontend 服 务 来 实现 整个 系统 的 搭建 。 


浏览 器 访问 
/ 


} 





\ 
\ 
1 


frontend Service 








图 2.5 ”Kubernetes 部 署 架 构图 


2.3.1 创建 redis-master RC 和 Service 


我 们 可 以 先 定 义 Service， 然 后 定义 一 个 RC 来 创建 和 控制 相关 联 的 
Pod， 或 者 先 定义 RC 来 创建 Pod， 然 后 定义 与 之 关联 的 Service， 这 里 我 
们 采用 后 一 种 方法 。 


首先 为 redis-master 创 建 一 个 名 为 redis-master 的 RC 定 义 文件 redis- 
master-controller.yaml。yaml 的 语法 类 似 于 PHP 的 语法 ， 对 于 空格 的 个 数 
有 严格 的 要 求 ， 详 见 http:/yaml.org。 


apiVersion: v1 
kind: ReplicationController 
metadata: 
name: redis-master 
labels: 
name: redis-master 
spec: 
replicas: 1 
selector: 
name: redis-master 
template: 
metadata: 
labels: 
name: redis-master 


spec: 


containers: 

- name: master 
image: kubeguide/redis-master 
ports: 


- containerPort: 6379 


其 中 ，kind 字 段 的 值 为 "ReplicationController”， 表 示 这 是 一 个 RC; 
spec.selector 是 RC 的 Pod 选 择 器 ， 即 监控 和 管理 拥有 这 些 标签 (Label) 
的 Pod 实 例 ， 确 保 当 前 集群 上 始终 有 且 仅 有 replicas 个 Pod 实 例 在 运行 ， 
这 里 我 们 设置 replicas=1 表 示 只 运行 一 个 〈 名 为 redis-master 的 ) Pod 实 
例 ， 当 集群 中 运行 的 Pod 数 量 小 于 replicas 时 ，RC 会 根据 spec.template 段 
定义 的 Pod 模 板 来 生成 一 个 新 的 Pod 实 例 ，labels 属 性 指定 了 该 Pod 的 标 
签 ， 注 意 ， 这 里 的 labels 必 须 匹 配 RC 的 spec.selector， 否 则 此 RC 就 会 陷 
入 “只 为 他 人 做 媒 衣 ”的 悲惨 世界 中 ， 永 无 翻身 之 时 。 





创建 好 redis-master-controller.yaml 文 件 以 后 ， 我 们 在 Master 节 点 执行 
fi: kubectl create-f<config file>， 将 它 发 布 到 Kubernetes 集 群 中 ， 就 
完成 了 redis-master 的 创建 过 程 : 


$ kubectl create -f redis-master-controller.yaml 


replicationcontroller "redis-master" created 


系统 提示 “redis-master" 表 示 创 建成 功 。 然 后 我 们 用 kubectl 命 令 碍 看 
刚刚 创建 的 redis-master: 


$ kubectl get rc 
NAME DESIRED CURRENT AGE 


redis-master 1 1 5m 


接 下 来 运行 kubectl get pods 命 令 来 查看 当前 系统 中 的 Pod 列 表 信 息 ， 
我 们 看 到 一 个 名 为 redis-master-xxxxx 的 Pod 实 例 ， 这 是 Kubernetes 根 据 
redis-master 这 个 RC 的 定义 自动 创建 的 Pod。RC 会 给 每 个 Pod 实 例 在 用 户 
设置 的 name 后 补充 一 段 UUID， 以 区 分 不 同 的 实例 。 由 于 Pod 的 调度 和 
创建 需要 花费 一 定 的 时 间 ， 比 如 需要 一 定 的 时 间 来 确定 调度 到 哪个 节点 
上 ， 以 及 下 载 Pod 的 相关 镜像 ， 所 以 一 开始 我 们 看 到 Pod 的 状态 将 显示 为 
Pending。 当 Pod 成 功 创建 完成 以 后 ， 状 态 会 被 更 新 为 Running。 如 果 Pod 
一 直 处 于 Pending 状 态 ， 则 请 参看 第 5 章 的 得 错 说 明 。 








$ kubectl get pods 


NAME READY STATUS 


redis-master-b031i0 1/1 Running 


redis-master Pod 已 经 创建 并 正常 运行 了 ， 接 下 来 我 们 束 创 建 一 个 与 
之 关联 的 Service (服务 ) 定义 文件 (文件 名 为 redis-master- 
service.yaml) ， 完 整 的 内 容 如 下 : 


apiVersion: vi 
kind: Service 
metadata: 
name: redis-master 
labels: 
name: redis-master 
spec: 


ports: 


- port: 6379 
targetPort: 6379 
selector: 


name: redis-master 


其 中 metadata.name 是 Service 的 服务 名 (ServiceName) ， 
spec.selector 确 定 了 选择 哪些 Pod， 本 例 中 的 定义 表明 将 选择 设置 过 
name=redis-master 标 签 的 Po0d。port 属 性 定义 的 是 Service 的 虚拟 端口 号 ， 
targetPort 属 性 指定 后 端 Pod 内 容器 应 用 监听 的 端口 号 。 


运行 kubectl create 命 令 创建 该 service: 


$ kubectl create -f redis-master-service.yaml 


service "redis-master" created 


系统 提示 “service”redis-master“created” 表 示 创 建成 功 。 然 后 运行 
kubectl get 命 令 可 以 查看 到 刚刚 创建 的 service: 


$ kubectl get services 
NAME CLUSTER-IP EXTERNAL-IP POR’ 


redis-master 169.169.208.57<none> 6379/TCP 


注意 到 redis-master 服 务 被 分 配 了 一 个 值 为 169.169.208.57 的 虚拟 站 地 
址 ， 随 后 ，Kubernetes 和 集群 中 其 他 新 创建 的 Pod 就 可 以 通过 这 个 虚拟 IP 地 
址 + 端口 6379 来 访问 这 个 服务 了 。 在 本 例 中 将 要 创建 的 redis-slave 和 
frontend 两 组 Pod 都 将 通过 169.169.208.57: 6379 来 访问 redis-master 服 务 。 


但 由 于 IP 地 址 是 在 服务 创建 后 由 Kubernetes 系 统 自 动 分 配 的 ， 在 其 


他 Pod 中 无 法 预先 知道 某 个 Service 的 虚拟 IP 地 址 ， 因 此 需要 一 个 机 制 来 
找到 这 个 服务 。 为 此 ，Kubernetes 巧 妙 地 使 用 了 Linux 环 境 变量 
(Environment Variable) ， 在 每 个 Pod 的 容 右 里 都 增加 了 一 组 Service 相 
关 的 环境 变量 ， 用 来 记录 从 服务 名 到 虚拟 卫 地 址 的 映射 和 关系。 以 redis- 
master 服 务 为 例 ， 在 容器 的 环境 变量 中 会 增加 下 面 两 条 记录 : 





REDIS_MASTER_SERVICE_HOST=169 .169 ,144.74 
REDIS_MASTER_SERVICE_PORT=6379 


于 是 ，redis-slave 和 frontend 等 Pod 中 的 应 用 程序 就 可 以 通过 环境 变 
量 REDIS_MASTER_SERVICE_HOST 得 到 redis-master 服 务 的 虚拟 IP 地 
址 ， 通 过 环境 变量 REDIS_MASTER_SERVICE_PORT 得 到 redis-master 服 
务 的 端口 号 ， 这 样 惑 完成 了 对 服务 地 址 的 查询 功能 。 





2.3.2 ”创建 redis-slave RC 和 Service 


现在 我 们 已 经 成 功 启 动 了 redis-master 服 务 ， 接 下 来 我 们 继续 完成 
redis-slave 服 务 的 创建 过 程 。 在 本 案例 中 会 局 动 redis-slave 服 务 的 两 个 副 
本 ， 每 个 副本 上 的 Redis 进 程 都 与 redis-master 进 行 数据 同步 ， 与 redis- 
master 共 同 组 成 了 一 个 具备 读 写 分 离 能 力 的 Redis 集 群 。 留 言 板 的 PHP 网 
页 将 通过 访问 redis-slave 服 务 来 读 取 留 言 数据 。 与 之 前 的 redis-master 服 
务 的 创建 过 程 一 样 ， 首 先 创建 一 个 名 为 redis-slave 的 RC 定 义 文 件 redis- 


slave-controller.yaml， 完 整 内 容 如 下 : 





apiVersion: v1 
kind: ReplicationController 
metadata: 
name: redis-slave 
labels: 
name: redis-slave 
spec: 
replicas: 2 
selector: 
name: redis-slave 
template: 
metadata: 
labels: 


name: redis-slave 


spec: 

containers: 

- name: slave 
image: kubeguide/guestbook-redis-slave 
env: 
- name: GET_HOSTS_FROM 

value: env 

ports: 


- containerPort: 6379 


在 容器 的 配置 部 分 设置 了 一 个 环境 变量 GET_HOSTS_FROM=env， 
意思 是 从 环境 变量 中 获取 redis-master 服 务 的 IP 地 址 信息 。 





redis-slave 镜 像 中 的 启动 脚本 /run.sh 的 内 容 为 : 


if [[ ${GET_HOSTS_FROM: -dns} == "env" ]]; then 
redis-server --slaveof ${REDIS_MASTER_SERVICE_HOST} 63 
else 
redis-server --slaveof redis-master 6379 


fi 


在 创建 redis-slave Pod 时 ， 系 统 将 自动 在 容器 内 部 生成 之 前 已 经 创建 
好 的 redis-master service 相 关 的 环境 变量 ， 所 以 redis-slave 应 用 程序 redis- 
server 可 以 直接 使 用 环境 变量 REDIS_MASTER_SERVICE_HOST 来 获取 
redis-master 服 务 的 IP 地 址 。 


如 果 在 容器 配置 部 分 不 设置 该 epv， 则 将 使 用 redis-master 服 务 的 名 
称 “redis-master" 来 访问 它 ， 这 将 使 用 DNS 方式 的 服务 发 现 ， 需 要 预先 局 


动 Kubernetes 集 群 的 skydns 服 务 ， 详 见 2.5.4 节 的 说 明 。 


运行 kubectl create S: 


$ kubectl create -f redis-slave-controller.yaml 


Replicationcontrollers "redis-slave" created 
运行 kubectl get 命 令 查 看 RC: 


$ kubectl get rc 


NAME DESIRED CURRENT AGE 
redis-master 1 1 1h 
redis-slave 2 2 1h 


查看 RC 创建 的 Pod， 可 以 看 到 有 两 个 redis-slave Pod 在 运行 : 


$ kubectl get pods 


NAME READY STATUS 
redis-master-b031i0 1/1 Running 0 
redis-slave-10ahl 1/1 Running 
redis-slave-c5y10 1/1 Running 


然后 创建 redis-slave 服 务 。 类 似 于 redis-master 服 务 ， 与 redis-slave 相 
关 的 一 组 环境 变量 也 将 在 后 续 新 建 的 frontend Pod 中 由 系统 自动 生成 。 


配置 文件 redis-slave-service.yaml 的 内 容 如 下 : 


apiVersion: v1 


kind: Service 
metadata: 

name: redis-slave 

labels: 

name: redis-slave 

spec: 

ports: 

- port: 6379 

selector: 


name: redis-slave 


1847 kubectl @!] Æ Service: 


$ kubectl create -f redis-slave-service.yaml 


services/redis-slave 


通过 kubectl 人 查看 创建 的 Service: 


$ kubectl get services 


NAME CLUSTER-IP EXTERNAL -IP POR’ 
frontend 169.169.167.153 <nodes> 80/TC 
redis-master 169.169.208.57<none> 6379/TCP 


redis-slave 169.169.78.102<none> 6379/TCP 


2.3.3 创建 frontend RC 和 Service 





类 似 地 ， 定 义 frontend 的 RC 配置 文件 
内 容 如 下 : 


frontend-controller.yaml， 


apiversion: vi 
kind: ReplicationController 
metadata: 
name: frontend 
labels: 
name: frontend 
spec: 
replicas: 3 
selector: 
name: frontend 
template: 
metadata: 
labels: 
name: frontend 
spec: 
containers: 
- name: frontend 
image: kubeguide/guestbook-php- frontend 


env: 


- name: GET_HOSTS_FROM 
value: env 
ports: 


- containerPort: 80 


在 容器 的 配置 部 分 设置 了 一 个 环境 变量 GET_HOSTS_FROM=env， 
意思 是 从 环境 变量 中 获取 redis-master 利 redis-slave 服 务 的 IP 地 址 信息 。 





容器 镜像 名 为 kubeguide/guestbook-php-frontend， 该 镜像 中 所 包含 的 
PHP 的 留言 板 源码 (guestbook.php〉 如 下 : 


< ? 
set_include_path('.:/usr/local/lib/php' ); 
error_reporting(E_ALL); 
ini_set('display_errors', 1); 

require 'Predis/Autoloader.php'; 


Predis\Autoloader::register(); 


if (isset($_GET['cmd']) === true) { 
$host = 'redis-master'; 
if (getenv('GET_HOSTS_FROM') == '‘env') { 


$host = getenv( 'REDIS_ MASTER_SERVICE_HOST' ); 
} 
header('Content-Type: application/json'); 
if ($_GET['cmd'] == 'set') { 

$client = new Predis\Client([ 


'scheme' => 'tcp', 


'host' => $host, 
'port' => 6379, 
]); 


$client->set($_GET['key'], $_GET['value']); 


print('{"message": "Updated"}'); 


} else { 
$host = 'redis-slave'; 
if (getenv('GET_HOSTS_FROM') == 'env') { 


$host = getenv( 'REDIS_ SLAVE_SERVICE_HOST'); 
} 
$client = new Predis\Client([ 

"Scheme' => 'tcp', 

‘host ' => $host, 

‘port! => 6379, 
]); 


$value = $client->get($_GET['key']); 
print('{"data": "' . $value . '"}'); 
} 
} else { 
phpinfo(); 


jy 


这 段 PHP 代 码 的 意思 是 ， 如 果 是 一 个 set 请 求 〈 提 交 留 言 )》 ， 则 会 连 
接 到 redis-master 服 务 进行 写 数据 操作 ， 其 中 redis-master 服 务 的 虚拟 IP 地 
址 是 用 之 前 提 过 的 从 环境 变量 中 获取 的 方式 得 到 的 ， 端 口 使 用 默认 的 








6379 端 口号 〈 当 然 ， 也 可 以 使 用 环境 变 
量 "REDIS_MASTER_SERVICE_PORT' 的 值 ); 如 果 是 get 请 求 ， 则 会 连 
接 到 redis-slave 服 务 进行 读数 据 操作 。 


可 以 看 到 ， 如 果 在 容器 配置 部 分 不 设置 
env“GET_HOSTS_FROM”， 则 将 使 用 redis-master 或 redis-slave 服 务 名 来 
访问 这 两 个 服务 ， 这 将 使 用 DNS 方 式 的 服务 发 现 ， 需 要 预先 启动 
Kubernetes 集 群 的 skydns 服 务 ， 详 见 2.5.4 市 的 说 明 。 


运行 kubectl create 命 令 创 建 RC: 


$ kubectl create -f frontend-controller.yaml 


replicationcontrollers "frontend" created 


查看 已 创建 的 RC: 


$ kubectl get rc 


NAME DESIRED CURRENT AGE 

frontend 3 3 1h 

redis-master 1 1 1h 

redis-slave 2 2 1h 
再 查看 生成 的 Pod: 


$ kubectl get pods 
NAME READY STATUS 
redis-master-b0310 1/1 Running 


redis-slave-10ahl 1/1 Running 


redis-slave-c5y10 1/1 Running 


frontend -4011g 1/1 Running 0 
frontend -u9aq6 1/1 Running 
frontend-ygail 1/1 Running 0 


最 后 创建 frontend Service， 主 要 目的 是 使 用 Service 的 NodePort 给 
Kubernetes 集 群 中 的 Service 映 射 一 个 外 网 可 以 访问 的 端口 ， 这 样 一 来 ， 
外 部 网 络 就 可 以 通过 NodeIP+NodePort 的 方式 访问 集群 中 的 服务 了 。 


服务 定义 文件 frontend-service.yaml 的 内 容 如 下 : 


apiVersion: v1 
kind: Service 
metadata: 
name: frontend 
labels: 
name: frontend 
spec: 
type: NodePort 
ports: 
- port: 80 
nodePort: 30001 
selector: 


name: frontend 


这 里 的 关键 点 是 设置 type=NodePort 并 指定 一 个 NodePort 的 值 ， 表 示 
使 用 Node 上 的 物理 机 端口 提供 对 外 访问 的 能 力 。 需 要 注意 的 是 ， 


spec.ports.NodePort 的 端口 号 范围 可 以 进行 限制 (通过 kube-apiserver 的 局 
动 参数 --service-node-port-range 指 定 ) ， 默 认为 30000 一 32767， 如 果 指 
定 为 可 用 IP 范 围 之 外 的 其 他 端口 号 ， 则 Service 的 创建 将 会 失败 。 


运行 kubectl create 命 令 创 建 Service: 


$ kubectl create -f frontend-service.yaml 


Services "frontend" created 


通过 kubectl 人 查看 创建 的 Service: 


$ kubectl get services 


NAME CLUSTER-IP EXTERNAL - IP POR 
frontend 169.169.167.153 <nodes> 80/7 
redis-master 169.169.208.57<none> 6379/TC 


redis-slave 169.169.78.102<none> 6379/TC 


2.3.4 通过 浏览 器 访问 frontend 页 面 


经 过 上 面 的 三 个 步骤 就 搭建 好 了 Guestbook 留 言 板 系统 ， 总 共 包 括 3 
个 应 用 的 6 个 实例 ， 都 运行 在 Kubernetes 集 群 中 。 打 开 浏 览 器 ， 在 地 址 栏 
输入 http:/ 虚 拟 机 IP: 30001/， 将 看 到 如 图 2.6 所 示 的 网 页 ， 并 且 看 到 网 
页 上 有 一 条 留言 一 “Hello World! ”。 














Guestbook X 


e > C 192.168.1.130 


Guestbook 


Hello World! 








图 2.6 ENDI A AV el A S A 


尝试 输入 一 条 新 的 留言 “Hi Kubernetes! ”， 单 击 Submit 按 钮 ， 网 页 
将 会 在 原 留 言 的 下 方 显示 新 的 留言 ， 说 明 这 条 留言 已 经 被 成 功 加 入 
Redis 数 据 库 中 了 ， 如 图 2.7 所 示 。 


Guestbook 


e > C 192.168.1.130:30001 


Guestbook 


Hello World! 
Hi Kubernetes! 








图 2.7 ”在 留言 极 网 页 添加 新 的 留言 


通过 Guestbook 示 例 ， 可 以 看 到 Kubernetes 强 大 的 应 用 管理 功能 ， 用 
户 仅 需 通过 几 个 简单 的 YAML 配 置 承 能 完成 复杂 系统 的 搭建 ， 并 能 够 通 
过 Kubernetes 上 自动 实现 服务 发 现 和 负载 均衡 。 接 下 来 ， 让 我 们 深入 Pod 的 
应 用 、 配 置 、 调 度 管理 及 服务 的 应 用 ， 开 始 Kubernetes 应 用 管理 之 旅 。 


2.4 ”深入 掌握 Pod 


本 节 将 对 Kubernetes 如 何 发 布 和 管理 应 用 进行 详细 说 明和 示例 ， 主 
要 包括 Pod 和 容器 的 使 用 、Pod 的 控制 和 调度 管理 、 应 用 配置 管理 等 内 


i 


容 。 





2.4.1 Pod 定 义 详 解 


yaml 格 式 的 Pod 定 义 文件 的 完整 内 容 如 下 : 


apiVersion: vi 
kind: Pod 
metadata: 

name: string 

namespace: string 

labels: 
- name: string 
annotations: 
- name: string 
spec: 

containers: 

- name: string 
image: string 
imagePullPolicy: [Always | Never | IfNotPresent ] 
command: [string] 

args: [string] 
workingDir: string 
volumeMounts: 
- name: string 


mountPath: string 


readOnly: boolean 
ports: 

- name: string 
containerPort: int 
hostPort: int 
protocol: string 

env: 

- name: string 
value: string 

resources: 
limits: 

cpu: string 

memory: string 

requests: 
cpu: string 
memory: string 
livenessProbe: 

exec: 

command: [string] 
httpGet: 

path: string 

port: number 

host: string 

scheme: string 

httpHeaders: 

- name: string 


value: string 


tcpSocket: 
port: number 
initialDelaySeconds: 0 
timeoutSeconds: 0 
periodSeconds: 0 
successThreshold: 0 
failureThreshold: 0 
securityContext: 
privileged: false 
restartPolicy: [Always | Never | OnFailure] 
nodeSelector: object 
imagePullSecrets: 
- name: string 

hostNetwork: false 

volumes: 

- name: string 
emptyDir: {} 
hostPath: 

path: string 
secret: 

secretName: string 

items: 

- key: string 

path: string 

configMap: 

name: string 


items: 


- key: String 


path: string 


对 各 属性 的 详细 说 明 如 表 2.13 所 示 。 
表 2.13 ”对 Pod 定 义 文 件 模板 中 各 属性 的 详细 说 明 


取 值 类 型 | 是 否 必 选 取 值 说 明 


version String Required 版 本 号 ， 例 如 v1 








kind String Required Pod 





metadata Object Required 元 数据 





metadata.name String Required Pod 的 名 称 ， 命 名 规范 需 符 合 RFC 1035 规范 





metadata.namespace String Required Pod 所 属 的 命名 空间 ， 默 认为 “default” 





metadata.labels[] List 定义 标签 列表 








metadata.annotation[] List 自 定 义 注解 列表 





Spec Object Required Pod 中 容器 的 详细 定义 








spec.containers[] List Required Pod 中 的 容器 列表 





spec.containers[].name String Required 容器 的 名 称 ， 需 符合 REC 1035 规范 

















spec.containers[].image String Required 容器 的 镜像 名 称 


续 表 
属性 名 各 


spec.containers[].mmagePullPolicy String 获取 镜像 的 策略 ， 可 选 值 包括 : Always. Never. 
IfNotPresent， 默 认 值 为 Always。 
Always: 表示 每 次 部 尝试 重新 下 载 镜像 。 
IfNotPresent: 表示 如 果 本 地 有 该 镜像 ， 则 使 用 本 
地 的 镜像 ， 本 地 不 存在 时 下 载 镜像 。 
Never: 表示 仅 使 用 本 地 镜像 


= 
打包 时 使 用 的 nant 

jpeccontinerfiare tt | iam | 
peccontanert}workineDis [Sun | 的 TB 录 i 


spec-containers{] volumeMountsf] =a a e SOSA ae rh A fr ER 


spec.containers[] .volumeMounts[].name 引用 Pod 定义 的 共享 存储 卷 的 名 称 ， 需 使 用 
volumes[0] 部 分 定义 的 共享 存储 卷 名 称 


spec.contamers{].volumeMounts[].mountPath 存 鱼 卷 在 容器 内 Mount 的 绝对 路 径 ， 应 少 于 512 


个 字符 
[speccontainers[}volumeMountsfJzeadOnly [Boolean | esanka RUHR 
|zpec containers pore [oe | MORI 
| spec containers] ports name [Sting | [aoma | 
| pec containers[].ports[] containerPort |t | [MMOS 
spec.containers[].ports[].hostPort 容器 所 在 主机 需要 监听 的 端口 号 ， 默 认 与 

containerPort 相同 。 设 置 hostPort 时 ， 同 一 各 宿主 

机 将 无 法 启动 该 容器 的 第 2 份 副本 
| eeeonbinerDporcDprotocal (Seins || HDA, 支持 TcP 和 UDP, RUATCP | 
| eecerbierDeml (tat, | RTH MOR M 
[spec.contsinersflenvijname [Sting | =| SMEAR | 
[spec.contsinersflenvijvalue [Sting | Pem | 
eccmais (oer | id, US a 
|=pec containers[J resources limits | Object | | | 


ed ol 
一 cpu-shares 参数 
run --memory 人 参数 


[pee containers[ resources requests ob | [anmam | 
















续 表 
属性 名 称 取 值 类 型 | 是 否 必 选 | mam | 


一 heme 
数量 
spec.containers[].resources requests memory 内 存 请 求 ， 单 位 可 以 为 MiB、GiB 等 ， 容 器 启动 


jspecvolimes0 lui |  _ 。 | 在 该 pea 上 定义 的 共享 存储 卷 列表 


spec.volumes[].name 共享 存 鳍 卷 的 名 称 ， 在 一 个 Pod 中 每 个 存储 卷 定 
义 一 个 名 称 ， 应 符合 RFC 1035 规范 。 容 器 定义 部 
分 的 containers[].volumeMounts[].name 将 引用 该 
共享 存 鳍 卷 的 名 称 。 
volume 的 类 型 包括 : emptyDir 、hostpath 、 
gcePersistentDisk, awsElasticBlockStore. gitRepo. 
enn els ci E mer dari nin 
rbd 、flexVolume 、cinder 、cephfs 、flocker 、 
downwardAPI 、 fc . azureFile 、 configMap 、 
vsphereVolume, EJU EXSI volume, i 
volume 的 name 保持 唯一。 本 节 讲 解 emptyDir、 
hostpath secret, configMap 这 4 种 volume， 其 他 
FM volume 的 设置 方式 详 见 第 1 章 的 说 轩 


ES O emptyDir | emptyDir 的 存储 卷 , 表示 与 Pod 同 生命 周期 
| eee 其 值 为 一 个 空 对 象 : emptyDir: {} 


全 一 | ent y 

主机 的 目录 ， 通 过 volumes[]. hostPath path 指定 

== | ara 
目录 

= e ES 
secret 对 象 到 容器 内 部 

ee | ees e 
义 的 configMap 对 象 到 容器 内 部 


spec.volumes[] livenessProbe 对 Pod 内 各 容器 健康 检查 的 设置 ， 当 探测 无 响应 
几 次 之 后 ， 系 统 将 自动 重启 该 容器 。 可 以 设置 的 
方法 包括 : exec. httpGet 和 tepSocket。 对 一 个 容 
器 仅 需 设置 一 种 健康 检查 方法 


spec volumesll livenessProbe exee [Objet | | 对 Po 内 各 容器 健康 检查 的 设置 ，exee 方式 
| pec volumes i] livenessProbe exec commandi] [Stine | (ee 方式 需要 指定 的 命令 或 者 时 本 


spec.volumes[] livenessProbe.httpGet RY Pod 内 务 容器 健康 检查 的 设置 , HTTPGet 方式 。 
需 指 定 path、port 








续 表 

属性 名 称 取 值 类 型 取 值 说 明 
| specvohmes0 ivenessProbe tcpSocket | Object |__| 对 Pod 内 各 容器 健康 检查 的 设置，tcpSocket 方式 
spec volumes[]ivenessProbe initialDetaySeconds | Number | | 容器 启动 完成 后 进行 首次 探测 的 时 间 ， 单 位 为 和 


spec Volumes[] livenessProbe timeoutSeconds | Number 对 容器 健康 检查 的 探测 等 待 响应 的 超时 时 间 设 
置 ， 单 位 为 秒 ， 默 认为 1 秒 。 超 过 该 超时 时 间 设 
置 ， 将 认为 该 容器 不 健康 ， 将 重启 该 容器 

spec volumes[] livenessProbe periodSeconds | Number 对 容器 健康 检查 的 定期 探测 时 间 设 置 ， 单 位 为 秒 ， 
默认 为 10 秒 探测 一 次 








spec restartPolicy String Pod 的 重启 策略 ， 可 选 值 为 Always, OnFailure, 
默认 值 为 Always。 
Always: Pod 一 旦 终止 运行 , 则 无 论 容器 是 如 何 终 
止 的 ，kubelet 都 将 重启 它 。 
OnFailure: 只 有 Pod 以 非 零 退出 码 终 止 时 , kubelet 
才 会 重启 该 容器 。 如 果 容 器 正常 结束 〈 退 出 码 为 
0)， 则 kubelet 将 不 会 重启 它 。 
Never: Pod 终止 后 ，kubelet 将 退出 码 报告 给 
Master， 不 会 再 重启 该 Pod 

spec.nodeSelector Object 设置 NodeSelector 表示 将 该 Pod 调度 到 包含 这 些 
label 的 Node E, LA key:value 格式 指定 


spec.imagePullSecrets Object Pull 镜像 时 使 用 的 secret 名 称 ， 以 name:secretkey 
格式 指定 


spec hostNetwork Boolean 是 否 使 用 主机 网 络 模式 ， 默 认为 false。 如 果 设 置 
为 tue， 则 表示 容器 使 用 宿主 机 网 络 ， 不 再 使 用 
Docker 网 桥 ， 该 Pod 将 无 法 在 同一 台 宿 主机 上 启 
动 第 2 个 副本 


2.4.2 ”Pod 的 基本 用 法 





在 对 Pod 的 用 法 进行 次 明之 前 ， 有 必要 先 对 Docker 容 咒 中 应 用 的 运 
行 要 求 进行 说 明 。 


在 使 用 Docker 时 ， 可 以 使 用 docker run 命令 创建 并 局 动 一 个 容器 。 
而 在 Kubernetes 系 统 中 对 长 时 间 运 行 容 器 的 要 求 是 : 其 主 程序 需要 一 直 
在 前 台 执 行 。 如 果 我 们 创建 的 Docker 镜 像 的 启动 命令 是 后 台 执 行程 序 ， 
例如 Linux 脚 本 : 











nohup ./start.sh & 


则 在 kubelet 创 建 包含 这 个 容器 的 Pod 之 后 运行 完 该 命令 ， 即 认为 Pod 
执行 结束 ， 将 立刻 销毁 该 Pod。 如 果 为 该 Pod 定 义 了 
ReplicationController， 则 系统 将 会 监控 到 该 Pod 已 经 终止 ， 之 后 根据 RC 
定义 中 Pod 的 replicas 副 本 数量 生成 一 个 新 的 Pod。 而 一 旦 创建 出 新 的 
Pod， 就 将 在 执行 完 启 动 命令 后 ， 陷 入 无 限 循 环 的 过 程 中 。 这 就 是 
Kubernetes 需 要 我 们 自己 创建 的 Docker 镜 像 以 一 个 前 台 命 令 作为 启动 命 
令 的 原因 。 








对 于 无 法 改造 为 前 台 执 行 的 应 用 ， 也 可 以 使 用 开源 工具 Supervisor 
辅助 进行 前 台 运 行 的 功能 。Supervisor 提 供 了 一 种 可 以 同时 启动 多 个 后 
台 应 用 ， 并 保持 Supervisor 上 自身 在 前 台 执 行 的 机 制 ， 可 以 满足 Kubernetes 
对 容器 的 启动 要 求 。 关 于 Supervisor 的 安装 和 使 用 ， 请 参考 官网 
http://supervisord.org 的 文档 说 明 。 


接 下 来 对 Pod 对 容器 的 封装 和 应 用 进行 说 明 ，Pod 的 基本 用 法 为 : 
Pod 可 以 由 1 个 或 多 个 容器 组 合 而 成 。 


在 上 一 节 Guestbook 的 例子 中 ， 名 为 frontend 的 Pod 只 由 一 个 容器 组 
成 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: frontend 
labels: 
name: frontend 
spec: 
containers: 
- name: frontend 
image: kubeguide/guestbook-php-frontend 
env: 
- name: GET_HOSTS_FROM 
value: env 
ports: 


- containerPort: 80 


这 个 frontendPod 在 成 功 启动 之 后 ， 将 启动 1 个 Docker 容 器 。 


另 一 种 场景 是 ， 当 frontend 和 redis 两 个 容器 应 用 为 紧 耦 合 的 关系 ， 
应 该 组 合成 一 个 整体 对 外 提供 服务 时 ， 则 应 将 这 两 个 容器 打包 为 一 个 
Pod， 如 图 2.8 所 示 。 


Pod 


PFA $F AT 


frontend redis-master 
:80 localhost:6379 
localhost 


图 2.8 ”包含 两 个 容 占 的 Pod 
配置 文件 frontend-localredis-pod.yaml 如 下 : 


apiVersion: v1 
kind: Pod 
metadata: 

name: redis-php 

labels: 

name: redis-php 

spec: 

containers: 

- name: frontend 


image: kubeguide/guestbook-php-frontend:localredis 


ports: 
- containerPort: 80 
- name: redis 
image: kubeguide/redis-master 
ports: 


- containerPort: 6379 


JR —Podh & 4 4 4s YN ZBI A E Ud EN 1M gt ZH localhost 
可 以 通信 ， 使 得 这 一 组 容器 被 * 绑 定 ” 在 了 一 个 环境 中 。 





Docker 4s kubeguide/guestbook-php-frontend: localredis 的 PHP 网 
页 中 ， 直 接 通 过 URL 地 址 “Jocalhost: 6379” 对 同属 于 一 个 Pod 内 的 redis- 
master 进 行 访 问 。guestbook.php 的 内 容 如 下 : 


< ? 
set_include_path('.:/usr/local/lib/php' ); 
error_reporting(E_ALL); 
ini_set('display_errors', 1); 

require 'Predis/Autoloader.php'; 


Predis\Autoloader::register(); 


if (isset($_GET['cmd']) === true) { 
$host = 'localhost'; 
if (getenv('REDIS_ HOST') && strlen(getenv('REDIS_HOST' 
$host = getenv('REDIS_HOST'); 
} 
header('Content-Type: application/json'); 


if ($_GET['cmd'] == 'set') { 
$client = new Predis\Client([ 
'scheme' => 'tcp', 
‘host ' => $host, 
‘port! => 6379, 
]); 


$client->set($_GET['key'], $_GET['value']); 
print('{"message": "Updated"}'); 
} else { 
$host = 'localhost'; 
if (getenv('REDIS_HOST') && strlen(getenv( 'REDIS_HOS 
$host = getenv('REDIS_HOST'); 
} 
$client = new Predis\Client([ 
"Scheme' => 'tcp', 
‘host ' => $host, 
‘port! => 6379, 
]); 


$value = $client->get($_GET['key']); 
print('{"data": "' . $value . '"}'); 
} 
} else { 
phpinfo(); 


Lae 


运行 kubectl create 命 令 创建 该 Pod; 


$ kubectl create -f frontend-localredis-pod.yaml 


pod "redis-php" created 


查看 己 创 建 的 Pod: 


# kubectl get pods 
NAME READY STATUS RESTARTS AGE 


redis-php 2/2 Running 0 10m 


可 以 看 到 READY 信 息 为 2:22， 表 示 Pod 中 的 两 个 容器 都 成 功 运 行 
Ta 


查看 这 个 Pod 的 详细 信息 ， 可 以 看 到 两 个 容器 的 定义 及 创建 的 过 程 
(Event 事 件 信 息 ) 


# kubectl describe pod redis-php 


Name: redis-php 

Namespace: default 

Node: k8s/192.168.18.3 

Start Time: Thu, 28 Jul 2016 12:28:21 +0800 
Labels: name=redis-php 

Status: Running 

IP: 172.17.1.4 

Controllers: <none> 

Containers: 


frontend: 


Container ID: 

Image: 

Image ID: 

Port: 

State: 
Started: 

Ready: 


Restart Count: 


Environment Variables: 


redis: 
Container ID: 
Image: 
Image ID: 
Port: 
State: 

Started: 

Ready: 


Restart Count: 


Environment Variables: 


Conditions: 
Type Status 
Initialized True 
Ready True 
PodScheduled True 
Volumes: 


default-token-97j21: 


docker ://ccc8616f8df1fb1 
kubeguide/guestbook-php- 
docker://sha256:d014f673 
80/TCP 

Running 

Thu, 28 Jul 2016 12:28:2 
True 

0 


<none> 


docker ://c0b19362097cda6i 
kubeguide/redis-master 
docker ://sha256:405a0b58 
6379/TCP 

Running 

Thu, 28 Jul 2016 12:28:2 
True 

0 


<none> 


Type: Secret (a volume populated by a Secret) 


SecretName: default-token-97j21 


QoS Tier: 
Events: 
FirstSeen 
18m18m 
18m18m 
18m18m 
18m18m 
18m18m 
18m18m 


18m18m 


BestEffort 


LastSeen 


Count From 


{default-scheduler } 


{kubelet 
{kubelet 
{kubelet 
{kubelet 
{kubelet 
{kubelet 


k8s-node-1} 
k8s-node-1} 
k8s-node-1} 
k8s-node-1} 
k8s-node-1} 


k8s-node-1} 


SubobjectPath 


2.4.3 PPA Pod 


静态 Pod 是 由 kubelet 进 行 管理 的 仅 存 在 于 特定 Node 上 的 Pod。 它 们 
不 能 通过 API Server 进 行 管理 ， 无 法 与 ReplicationController、Deployment 
或 者 DaemonSet 进 行 关 联 ， 并 且 kubelet 也 无 法 对 它们 进行 健康 检查 。 静 
态 Pod 总 是 由 kubelet 进 行 创建 ， 并 且 总 是 在 kubelet 所 在 的 Node 上 运行 。 





创建 静态 Pod 有 两 种 方式 : 配置 文件 或 者 HTTP 方 式 。 
1) 配置 文件 方式 


首先 ， 需 要 设置 kubelet 的 局 动 参数 “--config”， 指 定 kubelet 需 要 监控 
的 配置 文件 所 在 的 目录 ，kubelet 会 定期 扫描 该 目录 ， 并 根据 该 目录 中 
的 .yaml 或 .json 文 件 进 行 创建 操作 。 


假设 配置 目录 为 /etc/kubelet.d/， 配 置 启动 参数 : -- 
config=/etc/kubelet.d/， 然 后 重启 kubelet 服 务 。 


在 目录 /etc/kubelet.d 中 放 入 static-web.yaml 文 件 ， 内 容 如 下 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: static-web 
labels: 


name: static-web 


spec: 
containers: 

- name: static-web 
image: nginx 
ports: 

- name: web 


containerPort: 80 


SZJ BAAD OA oi Aas: 


# docker ps 
CONTAINER ID IMAGE COMMAND CREATED STATUS 


2292ea231ab1 nginx "nginx -g ‘daemon off" 1 minu 


可 以 看 到 一 个 Nginx 容 器 已 经 被 kubelet 成 功 创 建 了 出 来 。 
到 Master 节 点 查看 Pod 列 表 ， 可 以 看 到 这 个 static pod: 


# kubectl get pods 
NAME READY STATUS RESTARTS 


static-web-node1 1/1 Running 0 


由 于 静态 Pod 无 法 通过 API Server 直 接管 理 ， 所 以 在 Master 节 点 尝试 
删除 这 个 Pod， 将 会 使 其 变 成 Pending 状 态 ， 且 不 会 被 删除 。 


# kubectl delete pod static-web-node1 


pod "static-web-nodei" deleted 


# kubectl get pods 
NAME READY STATUS RESTARTS l 


static-web-node1 0/1 Pending 0 1: 


删除 该 Pod 的 操作 只 能 是 到 其 所 在 Node 上 ， 将 其 定义 文件 static- 
web.yaml 从 /etc/kubelet.d 目 录 下 删除 。 


# rm /etc/kubelet.d/static-web.yaml 
# docker ps 
// 无 容器 正在 运行 。 





2.4.4 ”Pod 容 器 共享 Volume 


在 同一 个 Pod 中 的 多 个 容器 能 够 共享 Pod 级 别 的 存储 卷 Volume。 
Volume 可 以 定义 为 各 种 类 型 ， 多 个 容器 各 上 自 进 行 挂 载 操 作 ， 将 一 个 
Volume 挂 载 为 容器 内 部 需要 的 目录 ， 如 图 2.9 所 示 。 


Pod 


容器 ah 
tomcat busvbox 








图 2.9 ”Pod 中 多 个 容器 共享 volume 


在 下 面 的 例子 中 ，Pod 内 包含 两 个 容器 : tomcat 和 busybox， 在 Pod 
级 别 设置 Volume“app-logs”， 用 于 tomcat 向 其 中 写 日 志文 件 ，busybox 读 
日 志文 件 。 





配置 文件 pod-volume-applogs.yaml 的 内 容 如 下 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: volume-pod 
spec: 
containers: 
- name: tomcat 
image: tomcat 
ports: 
- containerPort: 8080 
volumeMounts: 
- name: app-logs 
mountPath: /usr/local/tomcat/logs 
- name: busybox 
image: busybox 
command: ["sh", "-c", "tail -f /logs/catalina*.log"] 
volumeMounts: 
- name: app-logs 
mountPath: /logs 
volumes: 
- name: app-logs 


emptyDir: {} 


这 里 设置 的 Volume 名 为 app-logs， 类 型 为 emptyDir (也 可 以 设置 为 
其 他 类 型 ， 详 见 第 1 童 对 Volume 概 念 的 说 明 ) ， 挂 载 到 tomcat 容 占 内 


的 /usrvlocaltomcatlogs 目 录 ， 同 时 挂 载 到 logreader 容 器 内 的 /logs 目 录 。 
tomcat 容 器 在 启动 后 会 向 /usr/local/tomcat/logs 目 录 中 写 文件 ，logreader 容 


aot FY VA BEES HAAN SCPE To 








logreader 容 器 的 启动 命令 为 tail-f/logs/catalina*.log， 我 们 可 以 通过 
kubectl logs 命 令 查 看 logreader 容 右 的 输出 内 容 : 


# kubectl logs volume-pod -c busybox 


29-Jul-2016 12:55: 
29-Jul-2016 12:55: 
29-Jul-2016 12:55: 
29-Jul-2016 12:55: 
29-Jul-2016 12:56: 


59. 
59. 
59. 
59. 
00. 


626 
722 
740 
794 
604 


INFO [localhost-startStop-1] or! 
INFO [localhost-startStop-1] or 
INFO [main] org.apache.coyote.Al 
INFO [main] org.apache.coyote.Al 


INFO [main] org.apache.catalina 


这 个 文件 即 为 tecmcat 生 成 的 日 志文 件 /usr/local/tomcat/logs/catalina. 
<date>.log 的 内 容 。 登 录 tomcat 容 器 进行 查看 : 


# kubectl exec -ti volume-pod -c tomcat -- ls /usr/local. 


catalina.2016-07-29.log 


localhost_access_log.2016-0 


host-manager .2016-07-29.log manager.2016-07-29.log 


# kubectl exec -ti volume-pod -c tomcat -- tail /usr/loci 


29-Jul-2016 12:55:59.722 INFO [localhost-startStop-1] or! 


29-Jul-2016 12:55:59.740 INFO [main] org.apache.coyote.Al 


29-Jul-2016 12:55:59.794 INFO [main] org.apache.coyote.Al 


29-Jul-2016 12:56:00.604 INFO [main] org.apache.catalina 


2.4.5 “Pod 的 配置 管理 








应 用 部 署 的 一 个 最 佳 实践 是 将 应 用 所 需 的 配置 信息 与 程序 进行 分 
离 ， 这 样 可 以 使 得 应 用 程序 被 更 好 地 复 用 ， 通 过 不 同 的 配置 也 能 实现 更 
灵活 的 功能 。 将 应 用 打包 为 容器 镜像 后 ， 可 以 通过 环境 变量 或 者 外 挂 文 
件 的 方式 在 创建 容器 时 进行 配置 注入 ， 但 在 大 规模 容器 集群 的 环境 中 ， 
对 多 个 容器 进行 不 同 的 配置 将 变 得 非常 复杂 。Kubernetesv1.2 版 本 提供 
了 一 种 统一 的 集群 配置 管理 方案 一 一 ConfigMap。 本 节 对 ConfigMap 的 
概念 和 用 法 进行 详细 描述 。 

















1.ConfigMap: 容器 应 用 的 配置 管理 

ConfigMap 供 容器 使 用 的 典型 用 法 如 下 。 

(1) 生成 为 容器 内 的 环境 变量 。 
(2) 设置 容器 启动 命令 的 启动 参数 〈 需 设置 为 环境 变量 ) 。 
(3) 以 Volume 的 形式 挂 载 为 容器 内 部 的 文件 或 目录 。 


ConfigMap 以 一 个 或 多 个 key: value 的 形式 保存 在 Kubernetes 系 统 中 
供应 用 使 用 ， 既 可 以 用 于 表示 一 个 变量 的 值 〈 例 如 apploglevel=info) ， 
也 可 以 用 于 表示 一 个 完整 配置 文件 的 内 容 《〈 例 如 server.xml=<? 


xml...>...) 





可 以 通过 yam] 配 置 文件 或 者 直接 使 用 kubectl create configmap 命 令 行 


的 方式 来 创建 ConfigMap。 


2.ConfigMap 的 创建 : yaml 文 件 方 式 


下 面 的 例子 cm-appvars.yaml 描 述 了 将 几 个 应 用 所 需 的 变量 定义 为 
ConfigMap 的 用 法 : 


cm-appvars.yaml 
apiversion: v1 
kind: ConfigMap 
metadata: 

name: cm-appvars 
data: 

apploglevel: info 


appdatadir: /var/data 


执行 kubectl create 命 令 创建 该 ConfigMap: 


$kubectl create -f cm-appvars.yaml 


configmap "cm-appvars" created 


查看 创建 好 的 ConfigMap: 


# kubectl get configmap 
NAME DATA AGE 


cm-appvars 2 3S 


# kubectl describe configmap cm-appvars 


Name: cm-appvars 
Namespace: default 
Labels: <none> 
Annotations: <none> 
Data 

appdatadir: 9 bytes 
apploglevel: 4 bytes 


# kubectl get configmap cm-appvars -o yaml 
apiversion: vi 
data: 
appdatadir: /var/data 
apploglevel: info 
kind: ConfigMap 
metadata: 
creationTimestamp: 2016-07-28T19:57:16Z 
name: cm-appvars 
namespace: default 
resourceVersion: "78709" 
selfLink: /api/vi/namespaces/default/configmaps/cm-app' 


uid: 7bb2e9c0-54fd-11e6 -9dcd-000c29dc2102 


FAKA- cm-appconfigfiles.yaml jik SPAS ACS MC (server.xml 
和 logging.properties 定 义 为 ConfigMap 的 用 法 ， 设 置 key 为 配置 文件 的 别 


名 ，value 则 是 配置 文件 的 全 部 文本 内 容 : 


cm-appconfigfiles.yaml 
apiVersion: v1 
kind: ConfigMap 
metadata: 
name: cm-appconfigfiles 
data: 
key-serverxml: | 
< xml version='1.0' encoding='utf-8' > 
<Server port="8005" shutdown="SHUTDOWN"> 
<Listener className="org.apache.catalina.startup.Version 
<Listener className="org.apache.catalina.core.AprLifecyc 
<Listener className= 
"org.apache.catalina.core.JreMemoryLeakPreventionListener" /> 
<Listener className= 
"org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" 
<Listener className= 
"org.apache.catalina.core.ThreadLocalLeakPreventionListener" 
<GlobalNamingResources> 
<Resource name="UserDatabase" auth="Container" 
type="org.apache.catalina.UserDatabase 
description="User database that can be 
factory="org.apache.catalina.users.Mem 
pathname="conf/tomcat-users.xml" /> 


</GlobalNamingResources> 


<Service name="Catalina"> 

<Connector port="8080" protocol="HTTP/1.1" 
connectionTimeout="20000" 
redirectPort="8443" /> 

<Connector port="8009" protocol="AJP/1.3" redirectPort="i 

<Engine name="Catalina" defaultHost="localhost"> 

<Realm className="org.apache.catalina.realm.LockOutRealm 

<Realm className="org.apache.catalina.realm.UserDatabase 
resourceName="UserDatabase"/> 

</Realm> 

<Host name="localhost" appBase="webapps" 

unpackWARs="true" autoDeploy="true"> 

<Valve className="org.apache.catalina.valves.AccessLogva. 

prefix="localhost_access_log" suffix= 


pattern="%h %1 %U %t &quot;%r&quot; %: 


</Host> 

</Engine> 

</Service> 

</Server> 

key-loggingproperties: "handlers 

=1catalina.org.apache.juli.FileHandler, 2localhost.o 
3manager.org.apache.juli.FileHandler, 4host-manager .« 
java.util.logging.ConsoleHandler\r\n\r\n.handlers= 1 

java.util.logging.ConsoleHandler\r\n\r\nicatalina.org.api 
= FINE\r\nicatalina.org.apache. juli.FileHandler.dire 


= catalina.\r\n\r\n2localhost.org.apache. juli.FileHa 


= ${catalina.base}/logs\r\n2localhost.org.apache. jul 
= FINE\r\n3manager.org.apache. juli.FileHandler.direc 


= manager.\r\n\r\n4host-manager.org.apache.juli.File 


${catalina.base}/logs\r\n4host -manager.org.apache. 
host-manager.\r\n\r\njava.util.logging.ConsoleHandle 
= java.util.logging.SimpleFormatter\r\n\r\n\r\norg.a 
= INFO\r\norg.apache.catalina.core.ContainerBase.[Ca 
= 2localhost.org.apache.juli.FileHandler\r\n\r\norg.. 
= INFO\r\norg.apache.catalina.core.ContainerBase. [Ca 
= 3manager.org.apache. juli.FileHandler\r\n\r\norg. api 
= INFO\r\norg.apache.catalina.core.ContainerBase.[Ca 


= Ahost-manager.org.apache. juli.FileHandler\r\n\r\n" 


执行 kubectl create tit + fi! 41% ConfigMap: 


$kubectl create -f cm-appconfigfiles.yaml 


configmap "cm-appconfigfiles" created 


查看 创建 好 的 ConfigMap: 


# kubectl get configmap cm-appconfigfiles 
NAME DATA AGE 


cm-appconfigfiles 2 14s 


# kubectl describe configmap cm-appconfigfiles 
Name: cm-appconfigfiles 


Namespace: default 


Labels: <none> 


Annotations: <none> 


Data 


key-loggingproperties: 1809 bytes 


key-serverxml: 1686 bytes 


查看 已 创建 的 ConfigMap 的 详细 内 容 ， 可 以 看 到 两 个 配置 文件 的 全 


# kubectl get configmap cm-appconfigfiles -0 yaml 

apiVersion: v1 

data: 

key-loggingproperties: "handlers = 1catalina.org.apache.. 
3manager.org.apache.juli.FileHandler, 4host-manager. 
java.util.logging.ConsoleHandler\r\n\r\n.handlers = 
java.util.logging.ConsoleHandler\r\n\r\nicatalina.or 
= FINE\r\nicatalina.org.apache. juli.FileHandler.dire 
= catalina.\r\n\r\n2localhost.org.apache. juli.FileHa 
= ${catalina.base}/logs\r\n2localhost.org.apache. jul 
= FINE\r\n3manager.org.apache. juli.FileHandler.direc 
= manager.\r\n\r\n4host-manager.org.apache. juli.File 
= ${catalina.base}/logs\r\n4host -manager.org.apache. 
host-manager.\r\n\r\njava.util.logging.ConsoleHandle 


= java.util.logging.SimpleFormatter\r\n\r\n\r\norg.a 


INFO\r\norg.apache.catalina.core.ContainerBase.[Ca 


2localhost.org.apache. juli.FileHandler\r\n\r\norg.i 


INFO\r\norg.apache.catalina.core.ContainerBase.[Ca 


3manager.org.apache. juli.FileHandler\r\n\r\norg.ap 


INFO\r\norg.apache.catalina.core.ContainerBase.[Ca 
= Ahost-manager.org.apache. juli.FileHandler\r\n\r\n" 

key-serverxml: | 

< xml version='1.0' encoding='utf-8' > 

<Server port="8005" shutdown="SHUTDOWN"> 

<Listener className="org.apache.catalina.startup.Version 

<Listener className="org.apache.catalina.core.AprLifecyc 

<Listener className="org.apache.catalina.core.JreMemoryL 

<Listener className="org.apache.catalina.mbeans.GlobalRe: 

<Listener className="org.apache.catalina.core.ThreadLoca 

<GlobalNamingResources> 

<Resource name="UserDatabase" auth="Container" 

type="org.apache.catalina.UserDatabase 

description="User database that can be 

factory="org.apache.catalina.users.Mem 

pathname="conf/tomcat-users.xml" /> 


</GlobalNamingResources> 


<Service name="Catalina"> 

<Connector port="8080" protocol="HTTP/1.1" 
connectionTimeout="20000" 
redirectPort="8443" /> 

<Connector port="8009" protocol="AJP/1.3" redirectPort=" 


<Engine name="Catalina" defaultHost="localhost"> 


<Realm className="org.apache.catalina.realm.LockOutRealm 

<Realm className="org.apache.catalina.realm.UserDatabase 
resourceName="UserDatabase"/> 

</Realm> 

<Host name="localhost" appBase="webapps" 

unpackWARs="true" autoDeploy="true"> 

<Valve className="org.apache.catalina.valves.AccessLogva 

prefix="localhost_access_log" suffix= 


pattern="%h %1 %u %t &quot;%r&quot; % 


</Host> 
</Engine> 
</Service> 
</Server> 
kind: ConfigMap 
metadata: 
creationTimestamp: 2016-07-29T00:52:18Z 
name: cm-appconfigfiles 
namespace: default 
resourceVersion: "85054" 
selfLink: /api/vi/namespaces/default/configmaps/cm-app 


uid: b30d5019-5526-11e6 - 9dcd -000c29dc2102 


3.ConfigMap 的 创建 : kubectl 命 令 行 方式 


不 使 用 yaml 文 件 ， 直 接 通 过 kubectl create ”configmap 也 可 以 创建 


ConfigMap， 可 以 使 用 参数 --from-file 或 --from-literal 指 定 内 容 ， 并 且 可 以 
在 一 行 命令 中 指定 多 个 参数 。 


(1) 通过 --from-file 参 数 从 文件 中 进行 创建 ， 可 以 指定 key 的 名 
称 ， 也 可 以 在 一 个 命令 行 中 创建 包含 多 个 key 的 ConfigMap， 语 法 为 : 


# kubectl create configmap NAME --from-file=[key=]source 





(2) 通过 --from-file 参 数 从 目录 中 进行 创建 ， 该 目录 下 的 每 个 配置 
文件 名 都 被 设置 为 key， 文 件 的 内 容 被 设置 为 value， 语 法 为 : 


# kubectl create configmap NAME --from-file=config-files 


(3) --from-literal 从 文本 中 进行 创建 ， 直 接 将 指定 的 key#=value# 创 | 
建 为 ConfigMap 的 内 容 ， 语 法 为 : 


# kubectl create configmap NAME --from-literal=key1i=valu 


下 面 对 这 几 种 用 法 举例 说 明 。 





例如 ， 当 前 目录 下 含有 配置 文件 server.xml， 可 以 创建 一 个 包含 该 
文件 内 容 的 ConfigMap: 


# kubectl create configmap cm-server.xml --from-file=ser' 


configmap "cm-server.xml" created 


# kubectl describe configmap cm-server.xml 


Name: cm-server. xml 


Namespace: default 


Labels: <none> 
Annotations: <none> 
Data 

server.xml: 6458 bytes 





假设 configfiles 目 录 下 包含 两 个 配置 文件 server.xml 和 
logging.properties， 创 建 一 个 包含 这 两 个 文件 内 容 的 ConfigMap: 


# kubectl create configmap cm-appconf --from-file=config 


configmap "cm-appconf" created 


# kubectl describe configmap cm-appconf 


Name: cm-appconf 
Namespace: default 

Labels: <none> 
Annotations: <none> 

Data 

logging.properties: 3354 bytes 
server.xml: 6458 bytes 


使 用 --from-literal 参 数 进行 创建 的 示例 如 下 : 


# kubectl create configmap cm-appenv --from-literal=logl 


configmap "cm-appenv" created 


# kubectl describe configmap cm-appenv 


Name: cm-appenv 
Namespace: default 
Labels: <none> 
Annotations: <none> 
Data 

appdatadir: 9 bytes 
loglevel: 4 bytes 


容器 应 用 对 ConfigMap 的 使 用 有 以 下 两 种 方法 。 
(1) 通过 环境 变量 获取 ConfigMap 中 的 内 容 。 


(2) 通过 Volume 挂 载 的 方式 将 ConfigMap 中 的 内 容 挂 载 为 容 右 内 
部 的 文件 或 目录 。 





4.ConfigMap 的 使 用 : 环境 变量 方式 
以 cm-appvars.yaml 为 例 : 


apiVersion: vi 


kind: ConfigMap 


metadata: 

name: cm-appvars 
data: 

apploglevel: info 


appdatadir: /var/data 


在 Pod“cm-test-pod” 的 定义 中 ， 将 ConfigMap“cm-appvars” 中 的 内 容 
以 环境 变量 (APPLOGLEVEL 和 APPDATADIR) 设置 为 容器 内 部 的 环 
境 变 量 ， 容 器 的 启动 命令 将 显示 这 两 个 环境 变量 的 值 (“env|grep 
APP”) : 


apiVersion: v1 
kind: Pod 
metadata: 

name: cm-test-pod 
spec: 

containers: 

- name: cm-test 

image: busybox 


command: [ "/bin/sh", "-c", "env | grep APP" ] 











env: 
- name: APPLOGLEVEL # 定义 环境 变量 名 称 
valueFrom: # key“apploglevel” X% MÁ 
configMapKeyRef: 
name: cm-appvars # 环境 变量 的 值 取 自 cm-appvar 
key: apploglevel # key 为 “apploglevel” 








- name: APPDATADIR # 定义 环境 变量 名 称 


valueFrom: # key“appdatadir” 对 应 的 . 





configMapKeyRef : 
name: cm-appvars # 环境 变量 的 值 取 自 cm-appvar 
key: appdatadir # key 为 “appdatadir” 


restartPolicy: Never 


使 用 kubectl create-f 命 令 创 建 该 Pod， 由 于 是 测试 Pod， 所 以 该 Pod 在 
执行 完 启动 命令 后 将 会 退出 ， 并 且 不 会 被 系统 目 动 重启 


(restartPolicy=Never) : 





# kubectl create -f cm-test-pod.yaml 


pod "cm-test-pod" created 


使 用 kubect get pods--show-all 查 看 已 经 停止 的 Pod: 


# kubectl get pods --show-all 
NAME READY STATUS RESTARTS A 
cm-test-pod 0/1 Completed 0 8: 


查看 该 Pod 的 日 志 ， 可 以 看 到 启动 命令 “envjgrep APP” 的 执行 结果 如 
J: 


# kubectl logs cm-test-pod 
APPDATADIR=/var/data 


APPLOGLEVEL=info 


说 明 容 器 内 部 的 环境 变量 使 用 ConfigMap cm-appvars 中 的 值 进行 了 
正确 的 设置 。 


5.ConfigMap 的 使 用 : volumeMount 模 式 


下 面 cm-appconfigfiles.yaml 的 例子 中 包含 两 个 配置 文件 的 定义 : 


server.Xml 和 ]logging.properties 。 


cm-appconfigfiles.yaml 
apiVersion: v1 
kind: ConfigMap 
metadata: 
name: cm-serverxml 
data: 
key-serverxml: | 
< xml version='1.0' encoding='utf-8' > 


<Server port="8005" shutdown="SHUTDOWN"> 


<Listener className="org.apache.catalina. 
<Listener className="org.apache.catalina. 
<Listener className="org.apache.catalina. 
<Listener className="org.apache.catalina. 


<Listener className="org.apache.catalina. 


<GlobalNamingResources> 


startup.Version 
core.AprLifecyc 
core. JreMemoryL 
mbeans.GlobalRe. 


core. ThreadLoca 


<Resource name="UserDatabase" auth="Container" 


type="org.apache.catalina.UserDatabase 


description="User database that can be 


factory="org.apache.catalina.users.Mem 


pathname="conf/tomcat-users.xml" /> 


</GlobalNamingResources> 


<Service name="Catalina"> 

<Connector port="8080" protocol="HTTP/1.1" 
connectionTimeout="20000" 
redirectPort="8443" /> 

<Connector port="8009" protocol="AJP/1.3" redirectPort=" 

<Engine name="Catalina" defaultHost="localhost"> 

<Realm className="org.apache.catalina.realm.LockOutRealm 

<Realm className="org.apache.catalina.realm.UserDatabase 
resourceName="UserDatabase"/> 

</Realm> 

<Host name="localhost" appBase="webapps" 

unpackWARs="true" autoDeploy="true"> 

<Valve className="org.apache.catalina.valves.AccessLogva 

prefix="localhost_access_log" suffix= 


pattern="%h %1 %u %t &quot;%r&quot; %: 


</Host> 

</Engine> 

</Service> 

</Server> 

key-loggingproperties: "handlers 
= icatalina.org.apache.juli.FileHandler, 2localhost.. 
3manager.org.apache.juli.FileHandler, 4host-manager. 
java.util.logging.ConsoleHandler\r\n\r\n.handlers = 

java.util.logging.ConsoleHandler\r\n\r\nicatalina.org.api 
= FINE\r\nicatalina.org.apache. juli.FileHandler.dire 


= catalina.\r\n\r\n2localhost.org.apache. juli.FileHa 


= ${catalina.base}/logs\r\n2localhost.org.apache. jul 
= FINE\r\n3manager.org.apache. juli.FileHandler.direc 


= manager.\r\n\r\n4host-manager.org.apache.juli.File 


${catalina.base}/logs\r\n4host -manager.org.apache. 
host-manager.\r\n\r\njava.util.logging.ConsoleHandle 
= java.util.logging.SimpleFormatter\r\n\r\n\r\norg.a 
= INFO\r\norg.apache.catalina.core.ContainerBase.[Ca 
= 2localhost.org.apache.juli.FileHandler\r\n\r\norg.. 
= INFO\r\norg.apache.catalina.core.ContainerBase. [Ca 
= 3manager.org.apache. juli.FileHandler\r\n\r\norg. api 
= INFO\r\norg.apache.catalina.core.ContainerBase.[Ca 


= Ahost-manager.org.apache. juli.FileHandler\r\n\r\n" 


在 Pod“cm-test-app” 的 定义 中 ， 将 ConfigMap“cm-appconfigfiles” 中 的 
内 容 以 文件 的 形式 mount 到 容 右 内 部 的 /configfiles 目 录 中 去 。Pod 配 置 文 
件 cm-test-app.yaml 的 内 容 如 下 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: cm-test-app 
spec: 
containers: 
- name: cm-test-app 
image: kubeguide/tomcat -app:v1 
ports: 


- containerPort: 8080 


volumeMounts: 





- name: serverxml # 引用 volume 名 
mountPath: /configfiles E 挂 载 到 容器 内 的 目录 
volumes: 
- name: serverxml # 定义 VOLume 名 
configMap: 
name: cm-appconfigfiles # 使 用 ConfigMap“cm-a 
items: 
- key: key-serverxml # key=key-serverxml 
path: server.xml # Value 将 server .xml 文 人 


- key: key-loggingproperties # key=key-loggingpr 


path: logging.properties # value 将 logging .pr 


创建 该 Pod: 


# kubectl create -f cm-test-app.yaml 


pod "cm-test-app" created 


登录 容器 ， 查 看 到 /configfiles 目 录 下 存在 server.xml 和 和 
logging.properties 文 件 ， 它 们 的 内 容 就 是 ConfigMap“cm-appconfigfiles” 中 
两 个 key 定 义 的 内 容 。 


# kubectl exec -ti cm-test-app -- bash 
root@cm-test-app:/# cat /configfiles/server.xml 
< xml version='1.0' encoding='utf-8' > 


<Server port="8005" shutdown="SHUTDOWN"> 


root@cm-test-app:/# cat /configfiles/logging.properties 


handlers = icatalina.org.apache.juli.AsyncFileHandler, 2 


如 果 在 引用 ConfigMap 时 不 指定 items， 则 使 用 volumeMount 方 式 在 
容器 内 的 目录 中 为 每 个 item 生 成 一 个 文件 名 为 key 的 文件 。 


Pod 配 置 文件 cm-test-app.yaml 的 内 容 如 下 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: cm-test-app 
spec: 
containers: 
- name: cm-test-app 
image: kubeguide/tomcat -app:v1 
imagePullPolicy: Never 
ports: 


- containerPort: 8080 


volumeMounts: 
- name: serverxml # 引用 volume 名 
mountPath: /configfiles # 挂 载 到 容器 内 的 目录 
volumes: 
- Name: serverxml # 定义 VOLume 名 





configMap: 


name: cm-appconfigfiles # 使 用 ConfigMap“cm-a 


创建 该 Pod: 


# kubectl create -f cm-test-app.yaml 


pod "cm-test-app" created 


登录 容器 ， 碍 看 到 /configfiles 目 录 下 存在 key-loggingproperties 和 key- 
serverxml 文 件 ， 文 件 的 名 称 来 自 ConfigMap cm-appconfigfiles 中 定义 的 两 
个 key 的 名 称 ， 文 件 的 内 容 则 为 value 的 内 容 : 


# ls /configfiles 


key-loggingproperties key-serverxml 


6. 使 用 ConfigMap 的 限制 条 件 


使 用 ConfigMap 的 限制 条 件 如 下 。 


ConfigMap 必 须 在 Pod 之 前 创建 。 

ConfigMap 也 可 以 定义 为 属于 某 个 Namespace。 只 有 处 于 相同 

Namespaces 中 的 Pod 可 以 引用 它 。 

ConfigMap 中 的 配额 管理 还 未 能 实现 。 

e kubelet 只 支持 可 以 被 APIServer 管 理 的 Pod 使 用 ConfigMap。kubelet 
在 本 Node 上 通过 --manifest-url 或 --config 自 动 创建 的 静态 Pod 将 无 法 
引用 ConfigMap。 

。 在 Pod 对 ConfigMap 进 行 挂 载 CvolumeMount) 操作 时 ， 容 器 内 部 只 

能 挂 载 为 “目录 ”， 无 法 挂 载 为 "文件 ”。 在 挂 载 到 容器 内 部 后 ， 目 录 








中 将 包含 ConfigMap 定 义 的 每 个 item， 如 果 该 目录 下 原先 还 有 其 他 
文件 ， 则 容器 内 的 该 目录 将 会 被 挂 载 的 ConfigMap 进 行 履 兰 。 如 果 
应 用 程序 需要 保留 原来 的 其 他 文件 ， 则 需要 进行 额外 的 处 理 。 可 以 
通过 将 ConfigMap 挂 载 到 容器 内 部 的 临时 目录 ， 再 通过 启动 脚本 将 
配置 文件 复制 或 者 链接 〈cp 或 link 操 作 ) 到 应 用 所 用 的 实际 配置 目 
K Po 





2.4.6 ”Pod 生 命 周 期 和 重启 策略 


Pod 在 整个 生命 周期 过 程 中 被 系统 定义 为 各 种 状态 ， 熟 悉 Pod 的 各 种 
状态 对 于 我 们 理解 如 何 设 置 Pod 的 调度 策略 、 重 局 朱 略 是 很 有 必要 的 。 





Pod 的 状态 包括 以 下 几 种 ， 如 表 2.14 所 示 。 
表 2.14 ”Pod 的 状态 


状态 值 描 R 
Pending API Server 已 经 创建 该 Pod, 但 Pod 内 还 有 一 个 或 多 个 容器 的 镜像 没有 创建 , 包括 正在 下 载 镜 像 的 过 程 
Running Pod 内 所 有 容器 均 已 创建 ， 且 至 少 有 一 个 容器 处 于 运行 状态 、 正 在 启动 状态 或 正在 重启 状态 














Succeeded Pod 内 所 有 容器 均 成 功 执行 退出 ， 且 不 会 再 重启 





Failed Pod 内 所 有 容器 均 已 退出 ， 但 至 少 有 一 个 容器 退出 为 失败 状态 
Unknown 由 于 某 种 原因 无 法 获取 该 Pod 的 状态 ， 可 能 由 于 网 络 通信 不 畅 导 致 

















Pod 的 重启 策略 (RestartPolicy) 应 用 于 Pod 内 的 所 有 容 堪 ， 并 且 仅 
在 Pod 所 处 的 Node 上 由 kubelet 进 行 判断 和 重 司 操作 。 当 茶 个 容器 异常 退 
出 或 者 健康 检查 GEIL FI) 失败 时 ，kubelet 将 根据 RestartPolicy 的 设 
置 来 进行 相应 的 操作 。 





Pod 的 重启 策略 包括 Always、OnFailure 和 Never， 默 认 值 为 Always。 








e Always: 当 容 器 失效 时 ， 由 kubelet 自 动 重启 该 容 右 。 

e OnFailure: 当 容 器 终止 运行 且 退 出 码 不 为 0 时 ， 由 kubelet 目 动 重启 
该 容器 。 

e Never: 不 论 容 器 运行 状态 如 何 ，kubelet 都 不 会 重启 该 容器 。 





kubelet 重 局 失 效 容器 的 时 间 间 隔 以 sync-frequency 乘 以 2n 来 计算 ， 例 


如 1、2、4、8 倍 等 ， 最 长 延 时 5 分 钟 ， 并 且 在 成 功 重 启 后 的 10 分 钟 后 重 
置 该 时 间 。 





Pod 的 重启 策略 与 控制 方式 奶奶 相关 ， 当 前 可 用 于 管理 Pod 的 控制 器 
包括 ReplicationController、Job、DaemonSet 及 直接 通过 kubelet 管 理 〈( 静 
态 Pod) 。 每 种 控制 器 对 Pod 的 重启 策略 要 求 如 下 。 


e RC 和 DaemonSet: 必须 设置 为 Always， 需 要 保证 该 容器 持续 运行 。 
e Job: OnFailure 或 Never， 确 保 容器 执行 完成 后 不 再 重启 。 
e kubelet: 在 Pod 失 效 时 自动 重启 它 ， 不 论 RestartPolicy 设 置 为 什么 


值 ， 并 且 也 不 会 对 Pod 进 行 健康 检查 。 


结合 Pod 的 状态 和 重 司 稼 略 ， 表 2.15 列 出 一 些 和 常见 的 状态 转换 场 


A. 
JR o 


— Ihe i 


462.15 常见 的 状态 转换 场景 


Pod 的 结果 状态 





Pod 包含 的 容器 数 


Pod 当前 的 状态 


发 生 事 件 


RestartPolicy= 


Always 


RestartPolicy= 
OnFailure 


RestartPolicy= 
Never 





包含 1 个 容器 


Running 


容器 成 功 退 出 


Running 


Succeeded 


Succeeded 





包含 1 个 容器 


Running 


容器 失败 退出 


Running 


Running 


Failed 





包含 两 个 容器 


Running 





1 个 容器 失败 退出 





Running 





Running 





Running 





包含 两 个 容器 





Running 


容器 被 OOM 杀 掉 


Running 


Running 





Failed 


2.4.7 ”Pod 健康 检查 


对 Pod 的 健康 状态 检查 可 以 通过 两 类 探 针 来 检查 : LivenessProbe 和 


ReadinessProbe. 


e LivenessProbe 探 针 : 用 于 判断 容器 是 否 存 活 〈running 状 态 )， 如 果 
LivenessProbe 探 针 探测 到 容器 不 健康 ， 则 kubelet 将 杀 掉 该 容器 ， 并 
根据 容器 的 重启 策略 做 相应 的 处 理 。 如 果 一 个 容器 不 包含 
LivenessProbe 探 针 ， 那 么 kubelet 认 为 该 容器 的 LivenessProbe 探 针 返 
回 的 值 永 远 是 “Success”。 

e ReadinessProbe: 用 于 判断 容器 是 否 启 动 完成 (ready 状 态 ) ， 可 以 
接收 请 求 。 如 果 ReadinessProbe 探 针 检 测 到 失败 ， 则 Pod 的 状态 将 被 
修改 。Endpoint Controller 将 从 Service 的 Endpoint 中 删除 包含 该 容器 
所 在 Pod 的 Endpoint。 





kubelet 定 期 执行 LivenessProbe 探 针 来 诊断 容器 的 健康 状况 。 
LivenessProbe 有 以 下 三 种 实现 方式 。 





(1) ExecAction: 在 容 右 内 部 执行 一 个 命令 ， 如 果 该 命令 的 返回 
码 为 0， 则 表明 容 需 健康 。 








在 下 面 的 例子 中 ， 通 过 执行 “cat/tmp/health”* 命 令 来 判断 一 个 容器 运 
行 是 否 正 常 。 而 该 Pod 运 行 之 后 ， 在 创建 /tmp/health 文 件 的 10 秒 之 后 将 删 
除 该 文件 ， 而 LivenessProbe 健 康 检查 的 初始 探测 时 间 
(initialDelaySeconds) 为 15 秒 ， 探 测 结果 将 是 Faill， 将 导致 kubelet 杀 挥 
该 容器 并 重启 它 。 


apiVersion: v1 
kind: Pod 
metadata: 
labels: 
test: liveness 
name: liveness-exec 
spec: 
containers: 
- name: liveness 
image: gcr.io/google_containers/busybox 
args: 
- /bin/sh 
- -C 
- echo ok > /tmp/health; sleep 10; rm -rf /tmp/healt 
livenessProbe: 
exec: 
command: 
- cat 
- /tmp/health 
initialDelaySeconds: 15 


timeoutSeconds: 1 


(2) TCPSocketAction: 通过 容器 的 IP 地 址 和 端口 号 执行 TCP 检 
查 ， 如 果 能 够 建立 TCP 连 接 ， 则 表明 容器 健康 。 


在 下 面 的 例子 中 ， 通 过 与 容器 内 的 localhost: 80 建 并 TCP 连 接 进 行 
健康 检查 。 


apiVersion: v1 
kind: Pod 
metadata: 
name: pod-with-healthcheck 
spec: 
containers: 
- name: nginx 
image: nginx 
ports: 
- containerPort: 80 
livenessProbe: 
tcpSocket: 
port: 80 
initialDelaySeconds: 30 


timeoutSeconds: 1 


(3) HTTPGetAction: 通过 容器 的 耳 地 址 、 端 口号 及 路 径 调用 
HTTP Get 方 法 ， 如 果 响 应 的 状态 码 大 于 等 于 200 且 小 于 等 于 400， 则 认为 
容器 状态 健康 。 


在 下 面 的 例子 中 ，kubelet 定 时 发 送 HTTP 请 求 到 localhost: 
80/_status/healthz 来 进行 容器 应 用 的 健康 检查 。 


apiVersion: vi 
kind: Pod 
metadata: 


name: pod-with-healthcheck 


spec: 
containers: 
- name: nginx 
image: nginx 
ports: 
- containerPort: 80 
livenessProbe: 
httpGet: 
path: /_status/healthz 
port: 80 
initialDelaySeconds: 30 


timeoutSeconds: 1 


对 于 每 种 探测 方式 ， 都 需要 设置 initialDelaySeconds 和 
timeoutSeconds 两 个 参数 ， 它 们 的 含义 分 别 如 下 。 


e initialDelaySeconds: 局 动容 圳 后 进行 首次 健康 检查 的 等 待 时 间 ， 单 
位 为 秒 。 

e timeoutSeconds: 健康 检查 发 送 请 求 后 等 待 啊 应 的 超时 时 间 ， 单 位 
为 秒 。 当 超时 发 生 时 ，kubelet 会 认为 容器 已 经 无 法 提供 服务 ， 将 会 
重 局 该 容器 。 


2.4.8” 玩 转 Pod 调 度 





在 Kubernetes 系 统 中 ，Pod 在 大 部 分 场景 下 都 只 是 容器 的 载体 而 已 ， 
通常 需要 通过 RC、Deployment、DaemonSet、Job 等 对 象 来 完成 Pod 的 调 
度 与 自动 控制 功能 。 


1.RC、Deployment: 全 自动 调度 





RC 的 主要 功能 之 一 就 是 自动 部 车 一 个 容器 应 用 的 多 份 副本 ， 以 及 
持续 监控 副本 的 数量 ， 在 集群 内 始终 维持 用 户 指 定 的 副本 数量 。 


根据 frontend-controller.yaml 配 置 ， 用 户 需要 创建 3 个 
kubeguide/guestbook-php-frontend 应 用 的 副本 ， 在 将 该 定义 发 送 给 
Kubernetes 之 后 ， 系 统 将 在 集群 中 合适 的 Node 上 创建 3 个 Pod， 并 始终 维 
持 3 个 副本 的 数量 。 


apiversion: v1 
kind: ReplicationController 
metadata: 

name: frontend 

labels: 

name: frontend 

spec: 

replicas: 3 


selector: 


name: frontend 
template: 
metadata: 
labels: 
name: frontend 
spec: 
containers: 
- name: frontend 
image: kubeguide/guestbook-php-frontend 
env: 
- name: GET_HOSTS_FROM 
value: env 
ports: 


- containerPort: 80 


在 调度 策略 上 ， 除 了 使 用 系统 内 置 的 调度 算法 选择 合适 的 Node 进 行 
调度 ， 也 可 以 在 Pod 的 定义 中 使 用 NodeSelector 或 NodeAffinity 来 指定 满 
足 条 件 的 Node 进 行 调度 ， 下 面 我 们 分 别 进行 说 明 。 





1) NodeSelector: 定向 调度 


Kubernetes Master 上 的 Scheduler 服 务 〈kube-scheduler 进 程 ) 负责 实 
现 Pod 的 调度 ， 整 个 调度 过 程 通 过 执行 一 系列 复杂 的 算法 ， 最 终 为 每 个 
Pod 计 算出 一 个 最 佳 的 目标 节点 ， 这 一 过 程 是 自动 完成 的 ， 通 常 我 们 无 
法 知道 Pod 最 终 会 被 调度 到 哪个 节点 上 。 在 实际 情况 中 ， 也 可 能 需要 将 
Pod 调 度 到 指定 的 一 些 Node 上 ， 可 以 通过 Node 的 标签 (Label) 和 Pod 的 
nodeSelector 属 性 相 匹 配 ， 来 达到 上 述 目的 。 








(1) 首先 通过 kubect label 命 令 给 目标 Node 打 上 一 些 标签 


kubectl label nodes <node-name><label-key>=<label-value> 





这 里 ， 我 们 为 k8s-node-1 节 点 打上 一 个 zone=north 的 标签 ， 表 明 它 
是 “北方 ”的 一 个 节点 : 


$ kubectl label nodes k8s-node-1 zone=north 
NAME LABELS 


k8s-node-1 kubernetes.io/hostname=k8s -node-1, Zone=ni 


上 述 命令 行 操 作 也 可 以 通过 修改 资源 定义 文件 的 方式 ， 并 执行 
kubectl replace-f xxx.yaml 命 令 来 完成 。 


(2) 然后 ， 在 Pod 的 定义 中 加 上 nodeSelector 的 设置 ， 以 redis- 


master-controller.yaml 为 例 : 


apiversion: v1 
kind: ReplicationController 
metadata: 
name: redis-master 
labels: 
name: redis-master 
spec: 
replicas: 1 
selector: 
name: redis-master 


template: 


metadata: 
labels: 
name: redis-master 
spec: 
containers: 
- name: master 
image: kubeguide/redis-master 
ports: 
- containerPort: 6379 
nodeSelector: 


zone: north 


运行 kubectl create-f 命 令 创建 Pod，scheduler 就 会 将 该 Pod 调 度 到 拥有 
zone=north 标 签 的 Node 上 。 


使 用 kubectl get pods-o wide 命令 可 以 验证 Pod 所 在 的 Node: 


# kubectl get pods -o wide 
NAME READY STATUS RESTARTS AGI 


redis-master-f0rqj 1/1 Running 0 19s 


如 果 我 们 给 多 个 Node 都 定义 了 相同 的 标签 〈 例 如 zone=north) , Jl 
scheduler 将 会 根据 调度 算法 从 这 组 Node 中 挑选 一 个 可 用 的 Node 进 行 Pod 
调度 。 


通过 基于 Node 标 签 的 调度 方式 ， 我 们 可 以 把 集群 中 具有 不 同 特点 的 
Node 贴 上 不 同 的 标签 ， 例 
如 “role=frontend”“role=backend”“role=database” 等 标签 ， 在 部 署 应 用 时 就 





可 以 根据 应 用 的 需求 设置 NodeSelector 来 进行 指定 Node 范 围 的 调度 。 


需要 注意 的 是 ， 如 果 我 们 指定 了 Pod 的 nodeSelector 条 件 ， 且 集群 中 
不 存在 包含 相应 标签 的 Node， 则 即使 集群 中 还 有 其 他 可 供 使 用 的 
Node， 这 个 Pod 也 无 法 被 成 功 调度 。 


2) NodeAffinity: 48 AME Va 


NodeAffinity 意 为 Node 杀 和 性 的 调度 策略 ， 是 将 来 将 换 NodeSelector 
的 下 一 代 调 度 策略 。 由 于 NodeSelector 通 过 Node 的 Label 进 行 精确 匹配 ， 
所 以 NodeAffinity 增 加 了 In、NotIn、Exists、DoesNotExist、Gt、Lt 等 操 
作 符 来 选择 Node， 能 够 使 调度 策略 更 加 灵活 。 同 时 ， 在 NodeAffinity 中 
将 增加 一 些 信息 来 设置 杀 和 性 调度 策略 。 


e RequiredDuringSchedulingRequiredDuringExecution: 类 似 于 
NodeSelector， 但 在 Node 不 满足 条 件 时 ， 系 统 将 从 该 Node 上 移 除 之 
前 调度 上 的 Pod。 

e RequiredDuringSchedulingIgnoredDuringExecution: 与 第 1 个 
RequiredDuringSchedulingRequiredDuringExecution 的 作用 相似 ， 区 
别 是 在 Node 不 满足 条 件 时 ， 系 统 不 一 定 从 该 Node 上 移 除 之 前 调度 
上 的 Pod。 

e PreferredDuringSchedulingIgnoredDuringExecution: 指定 在 满足 调度 
条 件 的 Node 中 ， 哪 些 Node 应 更 优先 地 进行 调度 。 同 时 在 Node 不 满 
足 条 件 时 ， 系 统 不 一 定 从 该 Node 上 移 除 之 前 调度 上 的 Pod。 


在 当前 的 Alpha 版 本 中 ， 需 要 在 Pod 的 metadata.annotations 中 设置 
NodeAffinity 的 内 容 : 


apiVersion: v1 


kind: Pod 

metadata: 
name: with-labels 
annotations: 


scheduler.alpha.kubernetes.io/affinity: > 


{ 
"nodeAffinity": { 
"requiredDur ingSchedulingIgnoredDuringExecutio 
"nodeSelectorTerms": [ 
{ 
"matchExpressions": [ 
{ 

"key": "kubernetes.i0/e2e-az-name", 
"Operator": "In", 

"values": ["e2e-azi", "e2e-az2"]| 

} 
] 
} 
] 
} 
} 
} 
another-annotation-key: another-annotation-value 
spec: 
containers: 


- Name: with-labels 


image: gcr.io/google containers/pause:2.0 


这 里 NodeAffinity 的 设置 说 明 只 有 Node 的 Label 中 包含 
key=kubernetes.io/e2e-az-name， 并 有 日 其 value 为 “e2e-az1” 或 “e2e-az2” 时 ， 
才能 成 为 该 Pod 的 调度 目标 。 其 中 操作 符 为 m， 人 代表" 或 "运算 ， 其 他 操 
作 符 包括 NotIn〔 不 属于 ) 、Exists〈 存 在 一 个 条 件 ) 、 

DoesNotExist〈 不 存在 ) ~ Gt (KF) ~ Lt (小 于 ) 。 


如 果 同 时 设置 了 NodeSelector 和 NodeAffinity， 则 系统 将 需要 同时 满 
足 两 者 的 设置 才能 进行 调度 。 


在 未 来 的 Kubernetes 版 本 中 ， 还 将 加 入 Pod Arffinity 的 设置 ， 用 于 控 
制 当 调度 Pod 到 某 个 特定 的 Node 上 时 ， 判 断 是 否 有 其 他 Pod 正 在 该 Node 
行 ， 即 通过 其 他 的 相关 Pod 进 行 调 度 ， 而 不 仅仅 通过 Node 本 喘 的 标 


2.DaemonSet: 特定 场景 调度 


DaemonSet 是 Kubernetes 1.2 版 本 新 增 的 一 种 资源 对 象 ， 用 于 管理 在 
集群 中 每 个 Node 上 仅 运 行 一 份 Pod 的 副本 实例 ， 如 图 2.10 所 示 。 


在 每 个 Node 上 运 
行 一 个 monitor 
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图 2.10 DaemongSet 示 例 
这 种 用 法 适合 一 些 有 这 种 需求 的 应 用 。 


。 在 每 个 Node 上 运行 一 个 GlusterFS 存 储 或 者 Ceph 存 储 的 daemon 进 
程 。 

。 在 每 个 Node 上 运行 一 个 日 志 采 集 程序 ， 例 如 fluentd 或 者 logstach。 

。 在 每 个 Node 上 运行 一 个 健康 程序 ， 采 集 该 Node 的 运行 性 能 数据 ， 
例如 Prometheus Node Exporter, collectd, New Relic agent 或 者 


Ganglia gmond 等 。 


DaemonSet 的 Pod 调 度 策略 与 RC 类 似 ， 除 了 使 用 系统 内 置 的 算法 在 
台 Node 上 进行 调度 ， 也 可 以 在 Pod 的 定义 中 使 用 NodeSelector 或 
NodeAffinity 来 指定 满足 条 件 的 Node 范 围 进行 调度 。 


下 面 的 例子 定义 为 在 每 人 台 Node 上 启动 一 个 fluentd 容 费 ， 配 置 文件 
fluentd-ds.yaml 的 内 容 如 下 ， 其 中 挂 载 了 物理 机 的 两 个 目 
3X “/var/log” #l“/var/lib/docker/containers” : 


apiVersion: extensions/vibeta1 

kind: DaemonSet 

metadata: 
name: fluentd-cloud-logging 
namespace: kube-system 
labels: 


k8s-app: fluentd-cloud-logging 


spec: 
template: 
metadata: 
namespace: kube-system 
labels: 
k8s-app: fluentd-cloud-logging 
spec: 


containers: 

- name: fluentd-cloud-logging 
image: gcr.io/google_containers/fluentd-elastics: 
resources: 

limits: 
cpu: 100m 
memory: 200Mi 
env: 
- name: FLUENTD_ARGS 
value: -q 
volumeMounts: 


- name: varlog 


mountPath: /var/log 
readOnly: false 


- name: containers 


mountPath: /var/lib/docker/containers 


readOnly: false 
volumes: 
- name: containers 
hostPath: 
path: /var/lib/docker/containers 
- name: varlog 
hostPath: 


path: /var/log 


使 用 kubectl create fit S8 4 1% DaemonSet: 


# kubectl create -f fluentd-ds.yaml 


daemonset "fluentd-cloud-logging" created 


查看 创建 好 的 DaemonSet 和 Pod， 可 以 看 到 在 每 个 Node 上 都 创建 了 


一 个 Pod: 


# kubectl get daemonset --namespace=kube-system 


NAME DESIRED CURRENT 


fluentd-cloud-logging 2 2 


# kubectl get pods --namespace=kube-system 


NAME READY 


NODE -SELEC 


<none> 


STATUS 


fluentd-cloud-logging-7tw9z 1/1 Running 0 


fluentd-cloud-logging-aqdn1 1/1 Running 0 


3.Job: 批 处 理 调度 


Kubernetes 从 1.2 版 本 开始 文 持 批 处 理 类 型 的 应 用 ， 我 们 可 以 通过 
KubernetesJob 资 源 对 象 来 定义 并 局 动 一 个 批 处 理 任 务 。 批 处 理 任务 通 第 
并 行 〈 或 者 串 行 ) 启动 多 个 计算 进程 去 处 理 一 批 工 作 项 (work item) , 
处 理 完成 后 ， 整 个 批 处 理 任务 结束 。 按 照 批 处 理 任务 实现 方式 的 不 同 ， 
批 处 理 任务 可 以 分 为 如 图 2.11 所 示 的 几 种 模式 。 
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e Job Template Expansion 模 式 : 一 个 Job 对 象 对 应 一 个 待 处 理 的 Work 
item， 有 几 个 Work item 就 产生 几 个 独立 的 Job， 通 常 适合 Work item 
数量 少 、 每 个 Work ”item 要 人 处理 的 数据 量 比较 大 的 场景 ， 比 如 有 一 
个 100GB 的 文件 作为 一 个 Work item， 总 共 10 个 文件 需要 处 理 。 

e Queue with Pod Per Work Item 模 式 : 采用 一 个 任务 队列 存放 Work 
item， 一 个 Job 对 象 作 为 消费 者 去 完成 这 些 Work item， 在 这 种 模式 





下 ，Job 会 局 动 N 个 Pod， 每 个 Pod 对 应 一 个 Work item. 

e Queue with Variable Pod Count 模 式 : 也 是 采用 一 个 任务 队列 存放 
Work item， 一 个 Job 对 象 作为 消费 者 去 完成 这 些 Work item， 但 与 上 
面 的 模式 不 同 ，Job 启 动 的 Pod 数 量 是 可 变 的 。 








还 有 一 种 被 称 为 Single Job with Static Work Assignment 的 模式 ， 也 
是 一 个 Job 产 生 多 个 Pod 的 模式 ， 但 它 采 用 程序 静态 方式 分 配 任务 项 ， 而 
不 是 采用 队列 模式 进行 动态 分 配 。 


如 表 2.16 所 示 是 这 几 种 模式 的 一 个 对 比 。 


Pod 的 数量 少 于 | 用 户 程序 是 否 要 做 | Kubernetes 是 
Work item 相应 的 修改 否 支 持 


Job Template Expansion / / 是 


模式 名 称 











Queue with Pod Per Work Item 是 / 有 时 候 需 要 


Queue with Variable Pod Count 

















Single Job with Static Work Assignment | 是 / 是 





考虑 到 批 处 理 的 并 行 问 题 ，Kubernetes 将 Job 分 以 下 三 种 类 型 。 
1) Non-parallel Jobs 


通常 一 个 Job 只 局 动 一 个 Pod， 则 除非 Pod 异 常 ， 才 会 重启 该 Pod， 一 
旦 此 Pod 正 常 结束 ，Job 将 结束 。 


2) Parallel Jobs with a fixed completion count 


并 行 Job 会 启动 多 个 Pod， 此 时 需要 设 定 Job 的 .spec.completions 参 数 
为 一 个 正 数 ， 当 正常 结束 的 Pod 数 量 达 到 此 参数 设 定 的 值 后 ，Job 结 来。 
此 外 ，Job 的 .spec.parallelism 参 数 用 来 控制 并 行 度 ， 即 同时 启动 儿 个 Job 
来 处 理 Work Item. 


3) Parallel Jobs with a work queue 


任务 队列 方式 的 并 行 Job 需 要 一 个 独立 的 Queue，Work ”item 都 在 一 
个 Queue 中 存放 ， 不 能 设置 Job 的 .spec.completions 参 数 ， 此 时 Job 有 以 下 
ER PE 


。 每 个 Pod 能 独立 判断 和 决定 是 否 还 有 任务 项 需要 处 理 。 

。 如 果 某 个 Pod 正 党 结束 ， 则 Job 不 会 再 启动 新 的 Pod。 

。 如 果 一 个 Pod 成 功 结束 ， 则 此 时 应 该 不 存在 其 他 Pod 还 在 干 活 的 情 
况 ， 它 们 应 该 都 处 于 即将 结束 、 退 出 的 状态 。 

如 有 果 所 有 Pod 都 结束 了 ， 且 至 少 有 一 个 Pod 成 功 结束 ， 则 整个 Job 算 
是 成 功 结束 。 





下 面 我 们 分 别 说 说 常见 的 三 种 批 处 理 模 型 在 Kubernetes 中 的 例子 。 


首先 是 Job Template Expansion 模 式 ， 由 于 这 种 模式 下 每 个 Work item 
对 应 一 个 Job 实 例 ， 所 以 这 种 模式 首先 定义 一 个 Job 模 板 ， 模 板 里 主要 的 
参数 是 Work item 的 标识 ， 因 为 每 个 Job 处 理 不 同 的 Work item。 如 下 所 示 
的 Job 模 板 (文件 名 为 job.yaml.txt〉 中 的 $ITEM 可 以 作为 任务 项 的 标识 : 











apiVersion: batch/v1i 
kind: Job 
metadata: 
name: process-item-$ITEM 
labels: 
jobgroup: jobexample 
spec: 


template: 


metadata: 
name: jobexample 
labels: 
jobgroup: jobexample 
spec: 
containers: 
- name: c 
image: busybox 
command: ["sh", "-c", "echo Processing item $ITE 


restartPolicy: Never 


通过 下 面 的 操作 ， 生 成 3 个 对 应 的 Job 定 义 文 件 并 创建 Job: 


# for i in apple banana cherry 

> do 

> cat job.yaml.txt | sed "sS/\$ITEM/$i/" > ./jobs/job-$ 
> done 

# 1s jobs 

job-apple.yaml job-banana.yaml job-cherry.yaml 

# kubectl create -f jobs 

job "process-item-apple" created 

job "process-item-banana" created 


job "process-item-cherry" created 


观察 Job 的 运行 情况 : 


# kubectl get jobs -1 jobgroup=jobexample 


NAME DESIRED SUCCESSFUL AGE 


process-item-apple 1 1 4m 
process-item-banana 1 1 4m 
process-item-cherry 1 1 4m 


其 次 ， 我 们 看 看 Queue with Pod Per Work Item 模 式 ， 在 这 种 模式 下 
需要 一 个 任务 队列 存放 Work item， 比 如 RabbitMQ， 客 户 端 程序 先 把 要 
处 理 的 任务 变 成 Work ”item 放 入 到 任务 队列 ， 然 后 编写 Worker 程 序 并 打 
包 镜 像 并 定义 成 为 Job 中 的 Work Pod，Worker 程 序 的 实现 逻辑 是 从 任务 
队列 中 拉 取 一 个 Work item 并 人 处理， 处 理 完成 后 即 结束 进程 ， 图 2.12 给 出 
了 并 行 度 为 2 的 一 个 Demo 示 意图 。 


最 后 ， 我 们 再 看 看 Queue with Variable Pod Count 模式， 如 图 2.13 所 
示 ， 由 于 这 种 模式 下 ，Worker 程 序 需要 知道 队列 中 是 否 还 有 等 待 处 理 的 
Work ”item， 如 果 有 就 取出 来 并 处 理 ， 否 则 就 认为 所 有 工作 完成 并 结束 
进程 ， 所 以 任务 队列 通常 要 采用 Redis 或 者 数据 库 来 实现 。 





RabbitMQ 






K8s Job 
任意 时 刻 ， 最 多 只 有 2 个 Pod 存 在 
每 个 pod 对 应 一 个 工作 项 ， 即 处 理 完 一 个 ，Pod 就 结束 了 


产生 8 个 工作 项 








图 2.12 Queue with Pod Per Work Item 示 例 


RabbitMQ 并 不 能 让 客户 端 知道 是 否 
”没有 数据 SRP mR RAS). A 
此 这 里 采用 了 Redis 队 列 
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产生 8 个 工作 项 





每 个 pod 都 不 断 地 从 队列 中 拉 取 工作 项 并 处 理 ， 直到 队列 为 空 ， Pod 退 出 执行 ， 因此 ， 这 
种 情况 下 ， 只 要 有 一 个 Pod 成 功 结束 ， 就 意味 着 整个 Job 进 入 “终止 ”状态 。 


图 2.13 Queue with Variable Pod Count 示 例 


Kubernetes 对 Job 的 文 持 还 处 于 初级 阶段 ， 类 似 Linux Cron 的 定时 任 
务 也 还 没 时 间 ， 计 划 在 Kubernetes 1.4 中 实现 。 此 外 ， 更 为 复杂 的 流程 类 
的 批 处 理 框 架 也 还 没有 考虑 ， 但 随 着 Kubernetes 生 态 圈 的 不 断 发 展 和 壮 
大 ， 相 信 Kubernetes 在 批 处 理 方 面 也 会 有 更 多 的 规划 。 





2.4.9 Pod 的 扩容 和 缩 容 


在 实际 生产 系统 中 ， 我 们 经 常会 遇 到 某 个 服务 需要 扩容 的 场景 ， 也 
可 能 会 遇 到 由 于 资源 紧张 或 者 工作 负载 降低 而 需要 减少 服务 实例 数量 的 
场景 。 此 时 我 们 可 以 利用 RC 的 Scale 机 制 来 完成 这 些 工 作 。 以 redis-slave 
RC 为 例 ， 已 定义 的 最 初 副 本 数量 为 2， 通 过 kubect scale 命 令 可 以 将 
redis-slave RC 控制 的 Pod 副 本 数量 从 初始 的 2 更 新 为 3: 


$ kubectl scale rc redis-slave --replicas=3 


replicationcontroller "redis-slave" scaled 


执行 kubectl get pods 命 令 来 验证 Pod 的 副本 数量 增加 到 3: 


$ kubectl get pods 


NAME READY STATUS RESTARTS AGE 
redis-slave-4na2n 1/1 Running 0 1h 
redis-slave-92u3k 1/1 Running 0 1h 
redis-slave-palab 1/1 Running 0 2m 


将 --replicas 设 置 为 比 当 前 Pod 副 本 数量 更 小 的 数字 ， 系 统 将 会 “ 杀 
掉 ” 一 些 运 行 中 的 Pod， 以 实现 应 用 集群 缩 容 : 


$ kubectl scale rc redis-slave --replicas=1 


replicationcontroller "redis-slave" scaled 


$ kubectl get pods 
NAME READY STATUS RES 


redis-slave-4na2n 1/1 Running 0 


除了 可 以 手工 通过 kubectl ” scale 命令 完成 Pod 的 扩容 和 缩 容 操 作 ， 
Kubernetes v1.1 版 本 新 增 了 名 为 Horizontal Pod Autoscaler (HPA) 的 控 
制 问 ， 用 于 实现 基于 CPU 使 用 率 进 行 自 动 Pod 扩 缩 容 的 功能 。HPA 控 制 
器 基于 Master 的 kube-controller-manager 服 务 启动 参数 --horizontal-pod- 
autoscaler-sync-period 定 义 的 时 长 (默认 为 30 秒 〉 ， 周 期 性 地 监测 目标 
Pod 的 CPU 使 用 率 ， 并 在 满足 条 件 时 对 ReplicationController 或 Deployment 
中 的 Pod 副 本 数量 进行 调整 ， 以 符合 用 户 定 义 的 平均 Pod CPU 使 用 率 。 
PodCPU 使 用 率 来 源 于 heapster 组 件 ， 所 以 需要 预先 安装 好 heapster。 


创建 HPA 时 可 以 使 用 kubectlautoscale 命 令 进 行 快速 创建 或 者 使 用 
yaml 配 置 文件 进行 创建 。 在 创建 HPA 之 前 ， 需 要 已 经 存在 一 个 RC 或 
Deployment 对 象 ， 并 且 该 RC 或 Deployment 中 的 Pod 必 须 定义 
resources.requests.cpu 的 资源 请 求 值 ， 如 果 不 设 置 该 值 ， 则 heapster 将 无 
法 采集 到 该 Pod 的 CPU 使 用 情况 ， 会 导致 HPA 无 法 正常 工作 。 








下 面 通过 给 一 个 RC 设置 HPA， 然 后 使 用 一 个 客户 端 对 其 进行 压力 
测试 ， 对 HPA 的 用 法 进行 示例 。 


以 php-apache 的 RC 为 例 ， 设 置 cpu request 为 200m， 未 设置 limit 上 限 
的 值 : 


php-apache-rc.yaml 
apiVersion: v1 


kind: ReplicationController 


metadata: 
name: php-apache 
spec: 
replicas: 1 
template: 
metadata: 

name: php-apache 

labels: 
app: php-apache 

spec: 

containers: 

- name: php-apache 
image: gcr.io/google_containers/hpa-example 
resources: 

requests: 
cpu: 200m 
ports: 


- containerPort: 80 


# kubectl create -f php-apache-rc.yaml 


replicationcontroller "php-apache" created 


再 创建 一 个 php-apache 的 Service， 供 客户 端 访问 : 


php-apache-svc.yaml 
apiVersion: v1 


kind: Service 


metadata: 
name: php-apache 
spec: 
ports: 
- port: 80 
selector: 


app: php-apache 


# kubectl create -f php-apache-svc.yaml 


service "php-apache" created 


接 下 来 为 RC“php-apache” 创 建 一 个 HPA 控 制 器 ， 在 1 和 10 之 间 调 整 
Pod 的 副本 数量 ， 以 使 得 平均 Pod CPU 使 用 率 维持 在 50%。 


使 用 kubectl autoscale 命 令 进行 创建 : 


# kubectl autoscale rc php-apache --min=1 --max=10 --cpu 


或 者 通过 yaml 配 置 文件 来 创建 HPA， 需 要 在 scaleTargetRef 字 段 指定 
需要 管理 的 RC 或 Deployment 的 名 字 ， 然 后 设置 minReplicas、 
maxReplicas 和 targetCPUUtilizationPercentage 参 数 : 


hpa-php-apache.yaml 
apiVersion: autoscaling/v1i 
kind: HorizontalPodAutoscaler 
metadata: 


name: php-apache 


spec: 
scaleTargetRef: 
apiversion: v1 
kind: ReplicationController 
name: php-apache 
minReplicas: 1 
maxReplicas: 10 


targetCPUUtilizationPercentage: 50 


# kubectl create -f hpa-php-apache.yaml 


horizontalpodautoscaler "php-apache" created 


查看 已 创建 的 HPA: 


# kubectl get hpa 
NAME REFERENCE TARGET 


php-apache ReplicationController/php-apache 50% 


然后 ， 我 们 创建 一 个 busybox Pod， 用 于 对 php-apache 服 务 发 起 压力 
测试 的 请 求 : 


busybox- pod. yaml 
apiVersion: v1 
kind: Pod 
metadata: 

name: busybox 


spec: 


containers: 
- name: busybox 
image: busybox 


command: [ "sleep", "3600" | 


# kubectl create -f busybox-pod.yaml 


pod "busybox" created 


登录 busybox 容 器 ， 执 行 一 个 无 限 循环 的 wget 命 令 来 访问 php-apache 
服务 : 


# while true; do wget -q -0- http://php-apache > /dev/nu. 


注意 这 里 wget 的 目的 地 URL 地 址 是 Service 的 名 称 “php-apache”， 这 
要 求 DNS 服 务 正常 工作 ， 也 可 以 使 用 Service 的 虚拟 ClusterIP 地 址 对 其 进 
行 访问 ， 例 如 http://169.169.122.145: 


# kubectl exec -ti busybox -- sh 


/ # while true; do wget -q -0- http://php-apache > /dev/ 


等 待 一 段 时 间 后 ， 观 察 HPA 控 制 器 搜集 到 的 Pod CPU 使 用 率 : 


# kubectl get hpa 
NAME REFERENCE TARGET CURREN 


php-apache ReplicationController/php-apache 50% 3 


再 过 一 会 儿 ， 查 看 RC php-apache 副 本 数量 的 变化 : 


# kubectl get rc 
NAME DESIRED CURRENT AGE 
php-apache 10 10 23m 


可 以 看 到 HPA 已 经 根据 Pod 的 CPU 使 用 率 的 提高 对 RC 进 行 了 自动 扩 
容 ，Pod 副 本 数量 变 成 了 10 个 。 这 个 过 程 如 图 2.14 所 示 。 
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图 2.14 HPA 自 动 扩 容 


最 后 ， 我 们 停止 压力 测试 ， 在 busybox 的 控制 台 输 入 Ctrl+C， 停 止 无 
限 循 环 操作 。 


等 待 一 段 时 间 ， 观 察 HPA 的 变化 ; 


# kubectl get hpa 
NAME REFERENCE TARGET CURREN’ 


php-apache ReplicationController/php-apache 50% 


再 次 查看 RC 的 副本 数量 : 


NAME DESIRED CURRENT AGE 


php-apache 1 1 26m 


可 以 看 到 HPA 根 据 Pod CPU 使 用 率 的 降低 对 副本 数量 进行 了 缩 容 操 
作 ，Pod 副 本 数量 变 成 了 1 个 。 


当前 HPA 还 只 文 持 将 CPU 使 用 率 作 为 Pod 副 本 扩容 缩 容 的 触发 条 
件 ， 在 将 来 的 版 本 中 ， 将 会 文 持 应 用 相关 的 指标 例如 QPS Cqueries per 
second) 或 平均 啊 应 时 间作 为 触发 条 件 。 








2.4.10 “Pod 的 滚动 升级 


下 面 我 们 说 说 Pod 的 升级 问题 。 


当 集群 中 的 某 个 服务 需要 升级 时 ， 我 们 需要 停止 目前 与 该 服务 相关 
的 所 有 Pod， 然 后 重新 拉 取 镜像 并 局 动 。 如 果 集 群 规 模 比 较 大 ， 则 这 个 
工作 就 变 成 了 一 个 挑战 ， 而 且 先 全 部 停止 然后 逐步 升级 的 方式 会 导致 较 
长 时 间 的 服务 不 可 用 。Kubernetes 提 供 了 rolling-update( 深 动 升级 ) 功 

能 来 解决 上 述 问 题 。 





滚动 升级 通过 执行 kubect rolling-update 命 令 一 键 完成 ， 该 命令 创建 
了 一 个 新 的 RC， 然 后 自动 控制 旧 的 RC 中 的 Pod 副 本 的 数量 逐渐 减少 到 
0， 同 时 新 的 RC 中 的 Pod 副 本 的 数量 从 0 逐步 增加 到 目标 值 ， 最 终 实现 了 
Pod 的 升级 。 需 要 注意 的 是 ， 系 统 要 求 新 的 RC 需 要 与 上 昌 的 RC 在 相同 的 
命名 空间 (Namespace) 内 ， 即 不 能 把 别人 的 资产 偷偷 转移 到 上 自家 名 
下 。 滚 动 升级 的 过 程 如 图 2.15 所 示 。 
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图 2.15 “Pod 的 滚动 升级 


以 redis-master 为 例 ， 假 设 当前 运行 的 redis-master Pod 是 1.0 版 本 ， 则 
现在 需要 升级 到 2.0 版 本 。 


创建 redis-master-controller-v2.yaml 的 配置 文件 如 下 : 


apiVersion: v1 
kind: ReplicationController 
metadata: 
name: redis-master-v2 
labels: 
name: redis-master 
version: v2 
spec: 
replicas: 1 
selector: 
name: redis-master 
version: v2 
template: 
metadata: 
labels: 
name: redis-master 
version: v2 
spec: 
containers: 


- name: master 


image: kubeguide/redis-master:2.0 
ports: 


- containerPort: 6379 
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(1) RC 的 名 字 (name) 不 能 与 旧 的 RC 的 名 字 相 同 。 


(2) 在 selector 中 应 至 少 有 一 个 Label 与 旧 的 RC 的 Label 不 同 ， 以 标 
识 其 为 新 的 RC。 本 例 中 新 增 了 一 个 名 为 version 的 Label， 以 与 旧 的 RC 进 
行 区 分 。 


运行 kubectl rolling-update 命 令 完 成 Pod 的 滚动 升级 : 


kubectl rolling-update redis-master -f redis-master-cont 


kubectl 的 执行 过 程 如 下 : 


Creating redis-master-v2 

At beginning of loop: redis-master replicas: 2, redis-ma 
Updating redis-master replicas: 2, redis-master-v2 repli: 
At end of loop: redis-master replicas: 2, redis-master-v 
At beginning of loop: redis-master replicas: 1, redis-ma 
Updating redis-master replicas: 1, redis-master-v2 repli! 
At end of loop: redis-master replicas: 1, redis-master-v 
At beginning of loop: redis-master replicas: 0, redis-ma 
Updating redis-master replicas: ©, redis-master-v2 repli! 


At end of loop: redis-master replicas: 0, redis-master-v 


Update succeeded. Deleting redis-master 


redis-master-v2 


等 所 有 新 的 Pod 启 动 完 成 后 ， 
容器 集群 的 更 新 工作 。 


旧 的 Pod 也 被 全 部 销毁 ， 这 样 就 完成 了 





另 一 种 方法 是 不 使 用 配置 文件 ， 直 接 用 kubectl rolling-update 命 令 ， 
加 上 --image 参 数 指定 新 版 锐 像 名 称 来 完成 Pod 的 深 动 升级 : 


kubectl rolling-update redis-master --image=redis-master 


与 使 用 配置 文件 的 方式 不 同 ， 执 行 的 结果 是 旧 的 RC 被 删除 ， 新 的 


RC 仍 将 使 用 旧 的 RC 的 名 字 。 


kubectl 的 执行 过 程 如 下 : 


Creating redis-master-ea866a5d2c08588c3375b86fb253db75 


At beginning of loop: 


Updating redis-master 


At end of loop: redis- 


At beginning of loop: 


Updating redis-master 


At end of loop: redis- 


At beginning of loop: 


Updating redis-master 


At end of loop: redis- 


Update succeeded. Deleting old controller: 


redis-master replicas: 2, 


replicas: 2, redis-master- 


master replicas: 2, redis- 


redis-master replicas: 1, 


replicas: 1, redis-master- 


master replicas: 1, redis- 


redis-master replicas: 0, 


replicas: 0, redis-master- 


master replicas: 0, redis- 


redis-ma 
ea866a5d 
master-e 
redis-ma 
ea866a5d 
master-e 
redis-ma 
ea866a5d 


master -ei 


redis-master 


Renaming redis-master -ea866a5d2c08588c3375b86Fb253db75 tı 


redis-master 


可 以 看 到 ，kubectl 通 过 新 建 一 个 新 版 本 Pod， 停 挥 一 个 旧版 本 Pod,， 
逐步 迭代 来 完成 整个 RC 的 更 新 。 


更 新 完成 后 ， 碍 看 RC: 


$ kubectl get rc 
CONTROLLER CONTAINER(S) IMAGE(S) SELECTI 


redis-master master kubeguide/redis-master:2.0 


可 以 看 到 ，kubectl 给 RC 增加 了 一 个 key 为 “deployment” 的 Label (这 
个 key 的 名 字 可 通过 --deployment-label-key 参 数 进行 修改 ) ，Label 的 值 是 
RC 的 内 容 进 行 Hash 计 算 后 的 值 ， 相 当 于 签名 ， 这 样 就 能 很 方便 地 比较 


RC 里 的 Image 名 字 及 其 他 信息 是 否 发 生 了 变化 ， 它 的 具体 作用 可 以 参见 
第 6 章 的 源码 分 析 。 


如 果 在 更 新 过 程 中 发 现 配 置 有 误 ， 则 用 户 可 以 中 断 更 新 操作 ， 并 通 
过 执行 kubectl rolling-update-rollback 完 成 Pod 版 本 的 回 滚 : 


$ kubectl rolling-update redis-master --image=kubeguide/ 
Found existing update in progress (redis-master -fefd9752i 
Found desired replicas.Continuing update with existing ci 
At beginning of loop: redis-master -fefd9752aa5883ca4d530 
Updating redis-master -fefd9752aa5883ca4d53013a7b583967 ri 
At end of loop: redis-master -fefd9752aa5883ca4d53013a7b5:' 


Update succeeded. Deleting redis-master -fefd9752aa5883ca 


redis-master 


到 此 ， 可 以 看 到 Pod 恢 复 到 更 新 前 的 版 本 了 。 


2.5 TRA }EService 


Service 是 Kubernetes 最 核心 的 概念 ， 通 过 创建 Service， 可 以 为 一 组 
具有 相同 功能 的 容器 应 用 提供 一 个 统一 的 入 口 地 址 ， 并 且 将 请 求 进行 负 
载 分 发 到 后 端的 各 个 容器 应 用 上 。 本 市 对 Service 的 使 用 进行 详细 说 明 ， 
包括 Service 的 负载 均衡 、 外 网 访问 、DNS 服 务 的 搭建 、Ingress 7 层 路 由 
机 制 等 。 





2.5.1 Service 定 义 详解 


yaml 格 式 的 Service 定 义 文件 的 完整 内 容 如 下 : 


apiVersion: v1 // Required 
kind: Service // Required 
metadata: // Required 
name: string // Required 
namespace: string // Required 
labels: 


- name: string 
annotations: 


- name: string 


spec: // Required 
selector: [] // Required 
type: string // Required 


clusterIP: string 

sessionAffinity: string 

ports: 

- name: string 
protocol: string 
port: int 
targetPort: int 


nodePort: int 


Status : 
loadBalancer: 
ingress: 

ip: string 


hostname: string 


对 各 属性 的 说 明 如 表 2.17 所 示 。 
462.17 ”对 Service 的 定义 文件 模板 的 各 属性 的 说 明 


自 定义 标签 属性 列表 
自 定义 注解 属性 列表 
详细 描述 


d Label Selector 配置， 将 选择 共有 指定 Label 标签 的 Pod 作为 
管理 范围 


Service 的 类 型 ,指定 Service 的 访问 方式 , 默认 为 ClusterIP。 
ClusterIP: 虚拟 的 服务 IP 地 址 , 该 地 址 用 于 Kubemetes 集群 
内 部 的 Pod 访问 , 在 Node 上 kube-proxy 通过 设置 的 iptables 
规则 进行 转发 。 

NodePort: 使 用 宿主 机 的 端口 ， 使 能 够 访问 各 Node 的 外 部 客 
户 端 通过 Node 的 卫 地 址 和 端口 号 就 能 访问 服务 。 
LoadBalancer: 使 用 外 接 负载 均衡 器 完成 到 服务 的 负载 分 发 ， 
需要 在 spec.status.loadBalancer 字段 指定 外 部 负载 均 宇 器 的 


TP 地 址 ， 并 同时 定义 nodePort 和 clusterIpP， 用 于 公有 云 环 境 
WWR IP 地 址 ， 当 type=ClusterIP 时 ， 如 果 不 指定 ， 则 系 
统 进行 自动 分 配 ， 也 可 以 手工 指定 : 当 type=LoadBalancer 
时 ， 则 需要 指定 

是 否 支 持 Session， 可 选 值 为 ClientP， 默 认为 空 。 

ClientIP: 表示 将 同一 个 客户 端 (根据 客户 端的 也 地 址 决定 》 
的 访问 请 求 都 转发 到 同一 个 后 端 Pod 


端 
当 spec type=LoadBalancer 时 ,设置 外 部 负载 均衡 器 的 地 址 ， 
用 于 公有 云 环境 





2.5.2 Service 基 本 用 法 


一 般 来 说 ， 对 外 提供 服务 的 应 用 程序 需要 通过 某 种 机 制 来 实现 ， 对 
于 容器 应 用 最 简便 的 方式 就 是 通过 TCP/IP 机 制 及 监听 IP 和 端口 号 来 实 
现 。 例 如 ， 我 们 定义 一 个 提供 Web 服 务 的 RC， 由 两 个 tomcat 容 器 副本 组 
成 ， 每 个 容器 通过 containerPort 设 置 提 供 服 务 的 端口 号 为 8080: 








webapp-rc.yaml 
apiVersion: v1 
kind: ReplicationController 
metadata: 
name: webapp 
spec: 
replicas: 2 
template: 
metadata: 
name: webapp 
labels: 
app: webapp 
spec: 
containers: 
- name: webapp 
image: tomcat 


ports: 


-containerPort: 80 


创建 该 RC: 


# kubectl create -f webapp-rc.yaml 


replicationcontroller "webapp" created 


获取 Pod 的 IP 地 址 : 


# kubectl get pods -1 app=webapp -o yaml | grep podIP 
podIP: 172.17.1.4 
podIP: 172.17.1.3 


访问 这 两 个 Pod 提 供 的 Tomcat 服 务 : 


# curl 172.17.1.3:8080 
<!DOCTYPE html> 
<html lang="en"> 
<head> 
<meta charset="UTF-8" /> 
<title>Apache Tomcat/8.0.35</title> 
# curl 172.17.1.4:8080 
<!DOCTYPE html> 
<html lang="en"> 
<head> 


<meta charset="UTF-8" /> 


<title>Apache Tomcat/8.0.35</title> 


直接 通过 Pod 的 也 地 址 和 端口 号 可 以 访问 容器 应 用 ， 但 是 Pod 的 耳 地 
址 是 不 可 靠 的 ， 例 如 当 Pod 所 在 的 Node 发 生 故 障 时 ，Pod 将 被 Kubernetes 
重新 调度 到 另 一 台 Node 进 行 启动 ，Pod 的 了 地址 将 发 生变 化 。 更 重要 的 
是 ， 如 果 容 器 应 用 本 里 是 分 布 式 的 部 署 方式 ， 通 过 多 个 实例 共同 提供 服 
务 ， 就 需要 在 这 些 实例 的 前 病 设 置 一 个 负载 均衡 器 来 实现 请 求 的 分 发 。 
Kubernetes 中 的 Service 就 是 设计 出 来 用 于 解决 这 些 问 题 的 核心 组 件 。 





以 前 面 创 建 的 webapp 应 用 为 例 ， 为 了 让 客户 端 应 用 能 够 访问 到 两 个 
Tomcat Pod 实 例 ， 需 要 创建 一 个 Service 来 提供 服务 。Kubernetes 提 供 了 
一 种 快速 的 方法 ， 即 通过 kubectl expose 命 令 来 创建 Service: 


# kubectl expose rc webapp 


service "webapp" exposed 


查看 新 创建 的 Service， 可 以 看 到 系统 为 它 分 配 了 一 个 虚拟 的 IP 地 址 
(ClusterIP) ， 而 Service 所 需 的 端口 号 则 从 Pod 中 的 containerPort 复 制 而 
来 : 


# kubectl get svc 
NAME CLUSTER-IP EXTERNAL - IP PORT(S) 
webapp 169.169.235.79<none>8080/TCP 3s 


接 下 来 ， 我 们 就 可 以 通过 Service 的 IP 地 址 和 Service 的 端口 号 访问 该 


Service J : 


# curl 169.169.235.79:8080 
<!DOCTYPE html> 
<html lang="en"> 
<head> 
<meta charset="UTF-8" /> 


<title>Apache Tomcat/8.0.35</title> 


这 里 ， 对 Service 地 址 169.169.235.79: 8080 的 访问 被 自动 负载 分 发 
到 了 后 端 两 个 Pod 之 一 : 172.17.1.3: 8080 或 172.17.1.4: 8080。 


除了 使 用 kubectl expose 命 令 创建 Service， 我 们 也 可 以 通过 配置 文件 
定义 Service， 再 通过 kubectl create 命 令 进 行 创 建 。 例 如 对 于 前 面 的 
webapp 应 用 ， 我 们 可 以 设置 一 个 Service， 代 人 码 如 下 : 


apiVersion: v1 
kind: Service 
metadata: 
name: webapp 
spec: 
ports: 
- port: 8081 
targetPort: 8080 
selector: 


app: webapp 


Service 定 义 中 的 关键 字段 是 ports 和 selector。 本 例 中 ports 定 义 部 分 指 


定 了 Service 所 需 的 虚拟 端口 号 为 8081， 由 于 与 Pod 容 器 端口 号 8080 不 一 
样 ， 所 以 需要 再 通过 targetPort 来 指定 后 端 Pod 的 端口 号 。selector 定 义 部 
分 设置 的 是 后 端 Pod 所 拥有 的 label: app=webapp。 


创建 该 Service 并 查看 其 ClusterIP 地 址 : 


# kubectl create -f webapp-svc.yaml 


service "webapp" created 


# kubectl get svc 
NAME CLUSTER- IP EXTERNAL - IP PORT(S) 
webapp 169.169.28.190<none>8081/TCP 3s 


通过 Service 的 IP 地 址 和 Service 的 端口 号 进行 访问 : 


# curl 169.169.28.190:8081 
<!DOCTYPE html> 
<html lang="en"> 
<head> 
<meta charset="UTF-8" /> 


<title>Apache Tomcat/8.0.35</title> 


同样 ， 对 Service 地 址 169.169.28.190: 8081 的 访问 被 自动 负载 分 发 
到 了 后 端 两 个 Pod 之 一 : 172.17.1.3: 8080 或 172.17.1.4: 8080。 目 前 
Kubernetes 提 供 了 两 种 负载 分 发 策略 : RoundRobin 和 SessionAffinity， 具 
体 说 明 如 下 。 


e RoundRobin: 轮 询 模式 ， 即 轮 询 将 请 求 转发 到 后 端的 各 个 Pod 上 。 

e SessionAffinity: 基于 客户 端 耳 地 址 进行 会 话 保持 的 模式 ， 即 第 1 次 
将 某 个 客户 端 发 起 的 请 求 转发 到 后 端的 某 个 pod 上 ， 之 后 从 相同 的 
客户 端 必 起 的 请 求 都 将 被 转发 到 后 端 相同 的 Pod 上 。 


在 默认 情况 下 ，Kubernetes 采 用 RoundRobin 模 式 进 行路 由 选择 ， 但 
我 们 也 可 以 通过 将 service.spec.sessionAffinity 设 置 为 “ClientIP” 来 启用 
SessionAffinity 策 略 ， 这 样 ， 同 一 个 客户 端 发 来 的 请 求 束 会 建立 一 个 
Session， 并 且 对 应 到 后 端 固定 的 某 个 Pod 上 了 。 








在 某 些 应 用 场景 中 ， 开 发 人 员 和 希望 自己 控制 负载 均衡 的 策略 ， 不 使 
用 Service 提 供 的 默认 负载 均衡 的 功能 ，Kubernetes 通 过 Headless Service 
的 概念 来 实现 这 种 功能 ， 即 不 给 Service 设 置 ClusterIP〈 无 入 口 卫 地 
HE) ， 而 仅 通 过 Label Selector 将 后 端的 Pod 列 表 返 回 给 调用 的 客户 端 。 
例如 : 


apiVersion: v1 
kind: Service 
metadata: 

name: nginx 

labels: 

app: nginx 

spec: 

ports: 

- port: 80 

clusterIP: None 


selector: 


app: nginx 





该 Service 没 有 虚拟 的 ClusterIP 地 址 ， 对 其 进行 访问 将 获得 具有 
Label“app=nginx” 的 全 部 Pod 列 表 ， 然 后 客户 端 程序 需要 实现 自己 的 负载 
分 发 策略 ， 再 确定 访问 具体 哪 一 个 后 端的 Pod。 








在 某 些 环境 中 ， 应 用 系统 需要 将 一 个 外 部 数据 库 作 为 后 端 服务 进行 
连接 ， 或 将 另 一 个 集群 或 Namespace 中 的 服务 作为 服务 的 后 端 ， 这 时 可 
以 通过 创建 一 个 无 Label Selector 的 Service 来 实现 : 


kind: Service 
apiVersion: v1 
metadata: 

name: my-service 
spec: 

ports: 

- protocol: TCP 

port: 80 


targetPort: 80 


通过 该 定义 创建 的 是 一 个 不 带 标签 选择 器 的 Service， 即 无 法 选择 后 
端的 Pod， 系 统 不 会 自动 创建 Endpoint， 因 此 需要 手动 创建 一 个 和 该 
Service 同 名 的 Endpoint， 用 于 指 同 实际 的 后 端 访问 地 址 。 创 建 Endpoint 
的 配置 文件 内 容 如 下 : 





kind: Endpoints 


apiVersion: v1 


metadata: 
name: my-service 
subsets: 
- addresses: 
- IP: 1.2.3.4 
ports: 


- port: 80 


如 图 2.16 所 示 ， 访 问 没 有 标签 选择 器 的 Service 和 带 有 标签 选择 器 的 
Service 一 样 ， 请 求 将 会 被 路 由 到 由 用 户 手 动 定 义 的 后 端 Endpoint 上 。 
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图 2.16 ”Service 指 向 外 部 服务 


有 时 ， 一 个 容器 应 用 也 可 能 提供 多 个 端口 的 服务 ， 所 以 在 Service 的 
定义 中 也 可 以 相应 地 设置 为 多 个 端口 。 在 下 面 的 例子 中 ，Service 设 置 了 
两 个 端口 号 ， 并 且 为 每 个 端口 号 进行 了 命名 : 


apiVersion: v1 
kind: Service 


metadata: 


name: webapp 

spec: 

ports: 

- port: 8080 
targetPort: 8080 
name: web 

- port: 8005 
targetPort: 8005 
name: management 

selector: 


app: webapp 





Fy BY re PA is FS BE ASI i, BN TCPBKUDP: 


apiVersion: v1 
kind: Service 
metadata: 
name: kube-dns 
namespace: kube-system 
labels: 
k8s-app: kube-dns 
kubernetes.io/cluster-service: "true" 
kubernetes.io/name: "KubeDNS" 
spec: 
selector: 
k8s-app: kube-dns 
ClusterIP: 169.169.0.100 


ports: 

- name: dns 
port: 53 
protocol: UDP 

- name: dns-tcp 
port: 53 


protocol: TCP 


2.5.3 ”集群 外 部 访问 Pod 或 Service 


由 于 Pod 和 Service 是 Kubernetes 集 群 范围 内 的 虚拟 概念 ， 所 以 集群 外 
的 客户 问 系 统 无 法 通过 Pod 的 IP 地 址 或 者 Service 的 虚拟 IP 地 址 和 虚拟 端 
口号 访问 到 它们 。 为 了 让 外 部 客户 端 可 以 访问 这 些 服务 ， 可 以 将 Pod 或 
Service 的 端口 号 映射 到 宿主 机 ， 以 使 得 客户 端 应 用 能 够 通过 物理 机 访问 
容器 应 用 。 


1. 将 容器 应 用 的 端口 号 映射 到 物理 机 


(1) 通过 设置 容器 级 别 的 hostPort， 将 容器 应 用 的 端口 号 映射 到 物 
理 机 上 : 


pod-hostport.yaml 
apivVersion: vi 
kind: Pod 
metadata: 

name: webapp 

labels: 

app: webapp 

spec: 

containers: 

- name: webapp 


image: tomcat 


ports: 


- containerPort: 8080 


hostPort: 8081 


通过 kubectl create 命 令 创 建 这 个 Pod: 


# kubectl create -f pod-hostport.yaml 


pod "webapp" created 
通过 物理 机 的 卫 地 址 和 8081 端 口号 访问 Pod 内 的 容器 服务 : 


# curl 192.168.18.3:8081 
<!DOCTYPE html> 
<html lang="en"> 
<head> 
<meta charset="UTF-8" /> 


<title>Apache Tomcat/8.0.35</title> 


(2) 通过 设置 Pod 级 别 的 hostNetwork=true， 该 Pod 中 所 有 容器 的 端 
口号 都 将 被 直接 映射 到 物理 机 上 。 设 置 hostNetwork=true 时 需要 注意 ， 
在 容器 的 ports 定 义 部 分 如 果 不 指定 hostPort， 则 默认 hostPort 等 于 
containerPort， 如 果 指 定 了 hostPort， 则 hostPort 必 须 等 于 containerPort 的 


值 。 


pod-hostnetwork. yaml 


apiVersion: v1 


kind: Pod 
metadata: 

name: webapp 

labels: 
app: webapp 

spec: 

hostNetwork: true 

containers: 

- name: webapp 
image: tomcat 
imagePullPolicy: Never 
ports: 


- containerPort: 8080 
创建 这 个 Pod: 


# kubectl create -f pod-hostnetwork.yaml 


pod "webapp" created 


通过 物理 机 的 卫 地 址 和 8080 端 口号 访问 Pod 内 的 容器 服务 : 


# curl 192.168.18.4:8080 
<!DOCTYPE html> 
<html lang="en"> 
<head> 
<meta charset="UTF-8" /> 


<title>Apache Tomcat/8.0.35</title> 


2. 将 Service 的 端口 号 映射 到 物理 机 


(1) 通过 设置 nodePort 映 射 到 物理 机 ， 同 时 设置 Service 的 类 型 为 


NodePort: 


apiVersion: vi 
kind: Service 
metadata: 

name: webapp 

spec: 

type: NodePort 

ports: 

- port: 8080 
targetPort: 8080 
nodePort: 8081 

selector: 


app: webapp 


创建 这 个 Service: 


# kubectl create -f webapp-svc-nodeport.yaml 


You have exposed your service on an external port on all 


cluster. If you want to expose this service to the exte 


need to set up firewall rules for the service port(s) (ti 


See http://releases.k8s.io0/release-1.3/docs/user -guide/si 


service "webapp" created 


系统 提示 信息 说 明 : 由 于 要 使 用 物理 机 的 端口 号 ， 所 以 需要 在 防火 
载 上 做 好 相应 的 配置 ， 以 使 得 外 部 客户 端 能 够 访问 到 该 端口 。 


通过 物理 机 的 人 P 地 址 和 nodePort 8081 端 口号 访问 服务 : 


# curl 192.168.18.3:8081 
<!DOCTYPE html> 
<html lang="en"> 
<head> 
<meta charset="UTF-8" /> 


<title>Apache Tomcat/8.0.35</title> 


同样 ， 对 该 Service 的 访问 也 将 被 负载 分 发 到 后 端的 多 个 Pod 上 。 


(2) 通过 设置 LoadBalancer 映 射 到 云 服 务 商 提供 的 LoadBalancer 地 
址 。 这 种 用 法 仅 用 于 在 公有 云 服 务 提供 商 的 云 平 台 上 设置 Service 的 场 
景 。 在 下 面 的 例子 中 ，status.loadBalancer.ingress.ip 设 置 的 146.148.47.155 
为 云 服 务 商 提供 的 负载 均衡 器 的 耳 地 址 。 对 该 Service 的 访问 请 求 将 会 通 
过 LoadBalancer 转 发 到 后 端 Pod 上 ， 负 载 分 发 的 实现 方式 则 依赖 于 云 服 务 
商 提供 的 LoadBalancer 的 实现 机 制 。 


kind: Service 
apiVersion: v1 


metadata: 


name: my-service 


spec: 
selector: 
app: MyApp 
ports: 


- protocol: TCP 
port: 80 
targetPort: 9376 
nodePort: 30061 
ClusterIP: 10.0.171.239 
loadBalancerIP: 78.11.24.19 
type: LoadBalancer 
status: 
loadBalancer: 
ingress: 


- ip: 146.148.47.155 


2.5.4 DNS 服务 搭建 指南 


根据 第 1 革 对 Service 概 念 的 说 明 ， 为 了 能 够 通过 服务 的 名 字 在 集群 
内 部 进行 服务 的 相互 访问 ， 需 要 创建 一 个 虚拟 的 DNS 服 务 来 完成 服务 名 
到 ClusterIP 的 解析 。 本 节 将 对 如 何 搭建 DNS 服 务 进行 详细 说 明 。 





Kubernetes 提 供 的 虚拟 DNS 服务 名 为 skydns， 由 四 个 组 件 组 成 。 
(1) etcd: DNS 存储 。 


(2) kube2sky: 将 Kubernetes ”Master 中 的 Service (ik) 注册 到 
etcd 。 


(3) skyDNS: 提供 DNS 域名 解析 服务 。 
(4) healthz: 提供 对 skydns 服 务 的 健康 检查 功能 。 


图 2.17 描 述 了 KubernetesDNS 服 务 的 总 体 架 构 。 








Kubernetes 



































Master 
获取 Service 
信息 
| kube2sky | 
skyDNS ‘=< 
/ 
/ DNS 查询 
/ Service -> IP 


| 国 
Pod Pod | Rod 


V 访 问 Service pe 
7 ERA 
Node 1 __Kube-proxy jy #*#iPed Node 2 























图 2.17 Kubernetes DNS 服务 的 总 体 架 构 


1.skydns 配 置 文件 说 明 


skydns 服 务 由 一 个 RC 和 一 个 Service 的 定义 组 成 ， 分 别 由 配置 文件 
skydns-rc.yaml 和 和 skydns-svc.yaml 定 义 。 


skydns 的 RC 配置 文件 skydns-rc.yaml 的 内 容 如 下 ， 包 含 了 4 个 容器 的 
定义 : 


skydns-rc.yaml 

apiVersion: v1 

kind: ReplicationController 
metadata: 


name: kube-dns-vii 


namespace: kube-system 
labels: 
k8s-app: kube-dns 
version: v11 
kubernetes.io/cluster-service: "true" 
spec: 
replicas: 1 
selector: 
k8s-app: kube-dns 
version: v11 
template: 
metadata: 
labels: 
k8s-app: kube-dns 
version: vit 
kubernetes.io/cluster-service: "true" 
spec: 
containers: 
- name: etcd 
image: gcr.io/google_containers/etcd-amd64:2.2.1 
resources: 
limits: 
cpu: 100m 
memory: SOMi 
requests: 
cpu: 100m 


memory: SOMi 


command: 
- /usr/local/bin/etcd 
- -data-dir 
- /tmp/data 
- -listen-client-urls 
- http://127.0.0.1:2379,http://127.0.0.1:4001 
- -advertise-client-urls 
- http://127.0.0.1:2379,http://127.0.0.1:4001 
- -initial-cluster-token 
- skydns-etcd 
volumeMounts: 
- name: etcd-storage 
mountPath: /tmp/data 
name: kube2sky 
image: gcr.i0/google_containers/kube2sky-amd64:1 
resources: 
limits: 
cpu: 100m 
# Kube2sky watches all pods. 
memory: SOMi 
requests: 
cpu: 100m 
memory: SOMi 
livenessProbe: 
httpGet: 
path: /healthz 
port: 8080 


Scheme: HTTP 
initialDelaySeconds: 60 
timeoutSeconds: 5 
successThreshold: 1 
failureThreshold: 5 
readinessProbe: 
httpGet: 
path: /readiness 
port: 8081 
scheme: HTTP 
# we poll on pod startup for the Kubernetes ma 
# only setup the /readiness HTTP server once tl 
initialDelaySeconds: 30 
timeoutSeconds: 5 
args: 
# command = "/kube2sky" 
- --kube-master-url=http://192.168.18.3:8080 
- --domain=cluster.local 
- name: skydns 
image: gcr.io0/google_containers/skydns: 2015-10-11: 
resources: 
limits: 
cpu: 100m 
memory: SOMi 
requests: 
cpu: 100m 


memory: SOMi 


args: 
# command = "/skydns" 
- -machines=http://127.0.0.1:4001 
- -addr=0.0.0.0:53 
- -ns-rotate=false 
- -domain=cluster.local 
ports: 
- containerPort: 53 
name: dns 
protocol: UDP 
- containerPort: 53 
name: dns-tcp 
protocol: TCP 
name: healthz 
image: gcr.io0/google_containers/exechealthz:1.0 
resources: 
# keep request = limit to keep this container 
limits: 
cpu: 10m 
memory: 20M1 
requests: 
cpu: 10m 
memory: 20M1 
args: 
- -cmd=nslookup kubernetes.default.svc.cluster.1 
- -port=8080 


ports: 


- containerPort: 8080 
protocol: TCP 
volumes: 
- name: etcd-storage 
emptyDir: {} 


dnsPolicy: Default # Don't use cluster DNS. 





要 修改 的 儿 个 配置 参数 如 下 。 


(1) kube2sky 容 器 需要 访问 Kubernetes Master， 需 要 配置 Master 所 
在 物理 主机 的 人 P 地 址 和 端口 号 ， 本 例 中 设置 参数 --kube_master_url 的 值 
为 http://192.168.18.3: 8080。 


(2) kube2sky 容 器 和 skydns 容 器 的 启动 参数 --domain， 设 置 
Kubernetes 集 群 中 Service 所 属 的 域名 ， 本 例 中 为 “cluster.local”*”。 启 动 
后 ，kube2sky 会 通过 API ”Server 监 控 集 群 中 全 部 Service 的 定义 ， 生 成 相 
应 的 记录 并 保存 到 etcd 中 。kube2sky 为 每 个 Service 生 成 以 下 两 条 记录 。 





° <service_name>.<namespace_name>.<domain> o 


° <service_name>.<namespace_name>.svc.<domain>. o 


(3) skydns 的 启动 参数 -addr=0.0.0.0: 53 表 示 使 用 本 机 TCP 和 UDP 
的 53 端 口 提 供 服务 。 


skydns 的 Service 配 置 文件 skydns-svc.yaml 的 内 容 如 下 : 


skydns-svc.yaml 
apiVersion: v1 


kind: Service 


metadata: 
name: kube-dns 
namespace: kube-system 
labels: 
k8s-app: kube-dns 
kubernetes.io/cluster-service: "true" 
kubernetes.io/name: "KubeDNS" 
spec: 
selector: 
k8s-app: kube-dns 
ClusterIP: 169.169.0.100 


ports: 
- name: dns 
port: 53 


protocol: UDP 
- name: dns-tcp 
port: 53 


protocol: TCP 


注意 ，skydns 服 务 使 用 的 clusterIP 需 要 我 们 指 a i aE AIP Hh, 
址 ， 每 个 Node 的 kubelet 进 程 都 将 使 用 这 个 IP 地 址 ， 不 能 通过 Kubemetes 
自动 分 配 。 


男 外 ， 这 个 IP 地 址 需要 在 kube-apiserver 启 动 参 数 --service-cluster-ip- 
range 指 定 的 IP 地 址 范围 内 。 


在 创建 skydns 容 器 之 前 ， 先 修改 每 个 Node 上 kubelet 的 局 动 参数 。 


2. 修 改 每 台 Node 上 的 kubelet 启 动 参数 
修改 每 台 Node 上 kubelet 的 启动 参数 ， 加 上 以 下 两 个 参数 。 


e --cluster_dns=169.169.0.100: 为 DNS 服务 的 ClusterIP 地 址 。 
e --cluster_domain=cluster.local: 为 DNS 服务 中 设置 的 域名 。 


然后 重启 kubelet 服 务 。 


3. 创 建 skydnsRC 和 Service 


通过 kubectl create 完 成 skydns 的 RC 和 Service 的 创建 : 


#kubectl create -f skydns-rc.yaml 


#kubectl create -f skydns-svc.yaml 


查看 RC、Pod 和 Service， 确 保 容 器 成 功 启 动 : 


# kubectl get rc --namespace=kube-system 
NAME DESIRED CURR 
kube-dns-vii 1 1 


# kubectl get pods --namespace=kube-system 
NAME READY STAT 


kube-dns-vii-6diwu 4/4 Runn. 


# kubectl get services --namespace=kube-system 


NAME CLUSTER-IP EXTERNAL - IP POR 


kube-dns 169.169.0.100 <none> 53/U 


然后 ， 我 们 为 redis-master 应 用 创建 一 个 Service: 


redis-master-service.yaml 


apiVersion: v1 
kind: Service 
metadata: 
name: redis-master 
labels: 
name: redis-master 
spec: 
ports: 
- port: 6379 
targetPort: 6379 
selector: 


name: redis-master 


查看 创建 好 的 redis-master service: 


# kubectl get services 
NAME CLUSTER-IP EXTERNAL - IP POR’ 


redis-master 169.169.8.10 <none> 6379/ 


可 以 看 到 ， 系 统 为 redis-master 服 务 分 配 了 一 个 虚拟 IP 地 址 : 
169.169.8.10。 


到 此 ， 在 Kubernetes 集 群 内 的 虚拟 DNS 服 务 束 搭建 好 了 。 在 需要 访 
问 redis-master 的 应 用 中 ， 仅 需要 配置 上 redis-master Service 的 名 称 和 服务 
的 端口 号 ， 就 能 够 访问 到 redis-master 应 用 了 ， 让 我 们 回顾 一 下 redis- 
slave 应 用 需要 访问 redis-master 的 配置 内 容 : 


redis-slave 镜 像 的 启动 脚本 /run.sh 的 内 容 为 : 


if [[ ${GET_HOSTS_FROM:-dns} == "env" ]]; then 


redis-server --slaveof ${REDIS_MASTER_SERVICE_HOST} 63 
else 


redis-server --slaveof redis-master 6379 
Fi 


在 使 用 DNS 模式 的 情况 下 ，redis-slave 配 置 的 Master 地 址 为 : redis- 
master: 6379。 通 过 服务 名 进行 配置 ， 能 够 极 大 地 简化 客户 端 应 用 对 后 
端 服 务 变 化 的 感知 ， 包 括 服务 虚拟 IP 地 址 的 变化 、 服 务 后 端 Pod 的 变化 
等 ， 对 应 用 程序 的 微服 务 染 构 实现 提供 了 强 有 力 的 支撑 。 


4. 通 过 DNS 查找 Service 





接 下 来 使 用 一 个 带 有 nslookup 工 具 的 Pod 来 验证 DNS 服务 是 否 能 够 
正常 工作 : 


busybox.yaml 


apiversion: v1 
kind: Pod 


metadata: 


name: busybox 
namespace: default 
spec: 
containers: 
- name: busybox 
image: gcr.io/google_containers/busybox 
command: 
- sleep 


- "3600" 


运行 kubectl create-f busybox.yaml 完 成 创建 。 


在 该 容器 成 功 启动 后 ， 通 过 kubectl exec<container_id>nslookup 进 行 
测试 : 


# kubectl exec busybox -- nslookup redis-master 
Server: 169.169.0.100 
Address 1: 169.169.0.100 


Name: redis-master 


Address 1: 169.169.8.10 


可 以 看 到 ， 通 过 DNS 服务 器 169.169.0.100 成 功 找 到 了 名 为 “redis- 
master” 服 务 的 IP 地 址 : 169.169.8.10。 


如 果 某 个 Service 属 于 不 同 的 命名 空间 ， 那 么 在 进行 Service 人 查找 时 ， 
需要 带 上 namespace 的 名 字 。 下 面 以 查找 kube-dns 服 务 为 例 : 


# kubectl exec busybox -- nslookup kube-dns.kube-system 
server: 169.169.0.100 
Address 1: 169.169.0.100 


Name: kube-dns.kube-system 


Address 1: 169.169.0.100 


如 果 仅 使 用 "kube-dns” 来 进行 查找 ， 则 将 会 失败 : 


nslookup: can't resolve 'kube-dns' 


5.DNS 服 务 的 工作 原理 解析 
让 我 们 看 看 DNS 服务 背后 的 工作 原理 。 


(1) kube2sky 容 器 应 用 通过 调用 Kubernetes Master 的 API 获 得 集群 
中 所 有 Service 的 信息 ， 并 持续 监控 新 Service 的 生成 ， 然 后 写 入 etcd 中 。 


查看 etcd 中 存储 的 Service 信 息 : 


# kubectl exec kube-dns-v8-5tpm2 -c etcd --namespace=kub: 
/skydns/local/cluster/default 
/skydns/local/cluster/svc 


/skydns/local/cluster/kube-system 


可 以 看 到 在 skydns 键 下 面 ， 根 据 我 们 配置 的 域名 《〈cluster.local) Æ 
成 了 localcluster 子 键 ， 接 下 来 是 namespace 〈default 和 kube-system ) 和 


svc (下面 也 按 namespace 生 成 子 键 ) 。 


查看 redis-master 服 务 对 应 的 键 值 : 


# kubectl exec kube-dns-v8-5tpm2 -c etcd --namespace=kub: 


{"host":"169.169.8.10", "priority":10, "weight":10, "ttl":3 





可 以 看 到 ，redis-master 服 务 对 应 的 完整 域名 为 redis- 
master.default.cluster.ljocal， 并 且 其 下地 址 为 169.169.8.10。 


(2) 根据 kubelet 局 动 参数 的 设置 (--cluster_dns) ，kubelet 会 在 每 
个 新 创建 的 Pod 中 设置 DNS 域名 解析 配置 文件 /etc/resolv.conf 文 件 ， 在 其 
中 增加 了 一 条 nameserver 配 置 和 一 条 search 配 置 


nameserver 169.169.0.100 


search default.svc.cluster.local svc.cluster.local clust! 


it 4 FAR at 169.169.0.10077 [al HY SE Er E wt skydns 53% H E 
提供 的 DNS 解析 服务 。 


(3) 最 后 ， 应 用 程序 就 能 够 像 访问 网 站 域名 一 样 ， 仅 仅 通 过 服务 
的 名 字 就 能 访问 到 服务 了 。 


仍然 以 redis-slave 为 例 ， 假 设 已 经 启动 了 redis-slave Pod， 登 录 redis- 
slave 容 器 进行 查看 ， 可 以 看 到 其 通过 DNS 域名 服务 找到 了 redis-master 的 
IP 地 址 169.169.8.10， 并 成 功 建立 了 连接 。 


2.5.5 Ingress: HTTP 7 层 路 由 机 制 


根据 前 面 对 Service 的 使 用 说 明 ， 我 们 知道 Service 的 表现 形式 为 IP: 
Port， 即 工作 在 TCP/IP 层 。 而 对 于 基于 HTTP 的 服务 来 说 ， 不 同 的 URL 地 
址 经 常 对 应 到 不 同 的 后 端 服务 或 者 虚拟 服务 器 (Virtual Host) ， 这 些 应 
用 层 的 转发 机 制 仅 通过 Kubernetes 的 Service 机 制 是 无 法 实现 的 。 
Kubernetes v1.1 版 本 中 新 增 的 Ingress 将 不 同 URL 的 访问 请 求 转发 到 后 端 
不 同 的 Service， 实 现 HTTP 层 的 业务 路 由 机 制 。 在 Kubernetes 集 群 中 ， 
Ingress 的 实现 需要 通过 Ingress 的 定义 与 ngress ”Controller 的 定义 结合 起 
来 ， 才 能 形成 完整 的 HITP 负 载 分 发 功能 。 








图 2.18 显 示 了 一 个 典型 HTTP 层 路 由 的 例子 。 


e 对 http://mywebsite.com/api 的 访问 将 被 路 由 到 后 端 名 为 “api” 的 
Service. 

e 对 http://mywebsite.com/web 的 访问 将 被 路 由 到 后 端 名 为 “web” 的 
Service. 

e 对 http:/mywebsite.comy/doc 的 访问 将 被 路 由 到 后 端 名 为 “doc” 的 


Service 。 





service: service: service: 
http://api:80 http://web:80 http://docs:80 


api | | web | | docs 


图 2.18 ”Ingress 示 例 


1. 创 建 Ingress Controller 


在 定义 Ingress 之 前 ， 需 要 先 部 署 Ingress Controller， 以 实现 为 所 有 后 
端 Service 提 供 一 个 统一 的 入 口 。Ingress Controller 需 要 实现 基于 不 同 
HTTP URL 回 后 转发 的 负载 分 发 规则 ， 通 常 应 该 根据 应 用 系统 的 需求 进 
行 个 性 化 实现 。 如 果 公 有 云 服务 商 能 够 提供 该 类 型 的 HTTP 路 由 
LoadBalancer， 则 也 可 设置 其 为 Ingress Controller。 





在 Kubernetes 中 ，Ingress Controller 将 以 Pod 的 形式 运行 ， 监 控 
apiserver 的 /ingress 接 口 〈 在 1.3 版 本 中 
为 /apis/extensions/vlbetal/namespaces/<namespace_name>/ingresses 接 
口 ) 后 端的 backend services， 如 果 service 发 生变 化 ， 则 Ingress Controller 
应 自动 更 新 其 转发 规则 。 


在 下 面 的 例子 中 ， 我 们 使 用 Nginx 来 实现 一 个 Ingress Controller, jf 
要 实现 的 基本 逻辑 如 下 。 


(1) 监听 apiserver， 获 取 全 部 ingress 的 定义 。 


(2) 基于 ingress 的 定义 ， 生 成 Nginx 所 需 的 配置 文 
件 /etc/nginx/nginx.conf。 


(3) 执行 nginx-s ” reload 命令， 重新 加 载 nginx.conf 配 置 文件 的 内 


基于 Go 语言 的 代码 实现 如 下 : 


for { 


rateLimiter .Accept( ) 


ingresses, err := ingClient.List(labels.Everything() 

if err != nil || reflect.DeepEqual(ingresses.Items, 
continue 

} 

if w, err := os.Create("/etc/nginx/nginx.conf"); err 


log.Fatalf("Failed to open %v: %v", nginxConf, e 
} else if err := tmpl.Execute(w, ingresses); err != 
log.Fatalf("Failed to write template %v", err) 
} 


shellOut("nginx -s reload") 


我 们 可 以 通过 直接 下 载 谷歌 提供 的 nginx-ingress 镜 像 来 创建 Ingress 


Controller: 


nginx-ingress-rc.yaml 
apivVersion: v1 
kind: ReplicationController 
metadata: 
name: nginx-ingress 
labels: 
app: nginx-ingress 
spec: 
replicas: 1 
selector: 
app: nginx-ingress 
template: 
metadata: 
labels: 
app: nginx-ingress 
spec: 
containers: 
- image: gcr.io0/google_containers/nginx-ingress:0.: 
name: nginx 
ports: 
- containerPort: 80 


hostPort: 80 


这 里 ， 该 Nginx 应 用 设置 了 hostPort， 即 它 将 容器 应 用 监听 的 80 端 口 
号 映射 到 物理 机 ， 以 使 得 客户 端 应 用 可 以 通过 URL 地 址 “http:/ 物 理 机 





IP: 80” 来 访问 该 Ingress Controller. 
通过 kubectl create 命 令 创 建 该 RC: 


# kubectl create -f nginx-ingress-rc.yaml 


replicationcontroller "nginx-ingress" created 
# kubectl get pods 


NAME READY STATUS RESTARTS 


nginx-ingress-mrwtz 1/1 Running 0 


2. 定 义 Ingress 


为 mywebsite.com 定 义 Ingress， 设 置 到 后 端 Service 的 转发 规则 : 


apiVersion: extensions/vibetal 
kind: Ingress 
metadata: 

name: mywebsite-ingress 
spec: 

rules: 


- host: mywebsite.com 


http: 
paths: 
- path: /web 
backend: 


serviceName: webapp 


AGE 


2S 


servicePort: 80 


这 个 Ingress 的 定义 说 明 对 目标 URL http://mywebsite.com/web 的 访问 
将 被 转发 到 Kubernetes 的 一 个 Service 上 : webapp: 80。 


创建 该 Ingress: 


# kubectl create -f ingress.yaml 


ingress "mywebsite-ingress" created 


# kubectl get ingress 


NAME HOSTS ADDRESS PORTS , 


mywebsite-ingress mywebsite.com 80 





在 该 mgress 成 功 创建 后 ， 登 录 nginx-ingress Pod， 查 看 其 自动 生成 的 
nginx.conf 配 置 文件 内 容 : 


events { 
worker_connections 1024; 


} 
http { 


server { 


listen 80; 








server_name mywebsite.com; # Ingress 中 定义 的 虚拟 hos 


resolver 127.0.0.1; 


location /web { # Ingress 中 定义 的 路 径 . 





proxy_pass http://webapp; # service% 


3.1 faJhttp://mywebsite.com/web 


由 ne Controller 设 置 了 hostPort， 所 以 我 们 可 以 通过 其 所 在 的 
物理 机 对 其 0 问 。 可 以 在 物 ee 的 IP 地 
址 ， 也 可 以 通过 curl--resolve 进 行 指定 


$ curl --resolve mywebsite.com:80:192.168.18.3 mywebsite 


将 获得 Kubernetes Service“webapp: 80” 提 供 的 主页 。 


4.Imgress 的 发 展 路 线 


当前 的 Ingress 还 是 beta 版 本 ， 在 Kubernetes 的 后 续 版 本 中 将 增加 至 少 
以 下 功能 


© 文 持 更 多 TLS 选 项 ， 例 如 SNI、 重 加 密 等 。 

。 文 持 L4 和 L7 负 载 均衡 策略 (目前 只 支持 HTTP 层 的 规则 》〉。 

© 文 持 更 多 的 转发 规则 (目前 仪 支持 基于 URL 路 径 的 ) ， 例 如 重 定 回 
规则 、 会 话 保持 规则 等 。 





第 3 瘟 ”Kubernetes 核 心 原 理 


本 章 对 Kubernetes 的 核心 原理 进行 深入 分 析 ， 首 先 从 API Server 的 访 
问 开 始 讲 起 ， 然 后 分 析 Master 节 点 上 Controller Manager 各 个 组 件 的 功能 
实现 ， 以 及 Scheduler 预 选 算法 和 优选 算法 。 接 下 来 讲解 Node 节 点 上 的 
kubelet 和 kube-proxy 组 件 的 运行 机 制 。 最 后 ， 深 入 分 析 安 全 机 制 和 网 络 


原理 。 


3.1 Kubernetes API Server 原 理 分 析 


总 体 来 看 ，Kubernetes API Server 的 核心 功能 是 提供 了 Kubernetes 各 
类 资源 对 象 〈 如 Pod、RC、Service 等 ) 的 增 、 删 、 改 、 查 及 Watch 等 
HTTPRest 接 口 ， 成 为 集群 内 各 个 功能 模块 之 间 数 据 交 互 和 通信 的 中 心 
枢纽 ， 是 整个 系统 的 数据 总 线 和 数据 中 心 。 除 此 之 外 ， 它 还 有 以 下 一 些 
功能 特性 。 


(1) 是 集群 管理 的 API 入 口 。 
(2) 是 资源 配额 控制 的 入 口 。 


(3) 提供 了 完备 的 集群 安全 机 制 。 


3.1.1 Kubernetes API Server 概 述 


Kubernetes API Server 通 过 一 个 名 为 kube-apiserver 的 进程 提供 服 
务 ， 该 进程 运行 在 Master 节 点 上 。 在 默认 情况 下 ，kube-apiserver 进 程 在 
本 机 的 8080 端 口 〈 对 应 参数 --insecure-port) 提供 REST 服 务 。 我 们 可 以 
同时 启动 HITPS 安 全 端口 (--secure-port=6443) 来 启动 安全 机 制 ， 加 强 
REST API 访 问 的 安全 性 。 


通常 我 们 可 以 通过 命令 行 工 具 kubectl 来 与 Kubernetes API Server 交 
互 ， 它 们 之 间 的 接口 是 REST 调 用 。 为 了 测试 和 学 习 Kubernetes API 
Server 所 提供 的 接口 ， 我 们 也 可 以 使 用 cuzl 命 令 行 工具 进行 快速 验证 。 








比如 ， 我 们 登录 Master 节 上 点， 运行 下 面 的 curl 命 令 ， 得 到 以 JSON 方 
式 返 回 的 Kubernetes API 的 版 本 信息 : 


# curl localhost:8080/api 
{ 
"kind": "APIVersions", 
"versions": [ 
"yq" 
]， 
"serverAddressByClientCIDRs": [ 
{ 
"ClientCIDR": "0.0.0.0/0", 
"serverAddress": "192.168.18.131:6443" 





可 以 运行 下 面 的 命令 ， 来 查看 Kubernetes API Server 目 前 所 支持 的 
资源 对 象 的 种 类 : 


# curl localhost:8080/api/v1 





根据 以 上 命令 的 输出 ， 我 们 可 以 运行 下 面 的 curl 命 令 ， 分 别 返回 集 
群 中 的 Pod 列 表 、Service 列 表 、RC 列 表 等 : 


# curl localhost:8080/api/vi/pods 
# curl localhost:8080/api/vi/services 


# curl localhost:8080/api/vi/replicationcontrollers 


pene 只 想 对 外 其 露 部 分 REST 服 务 ， 则 可 以 在 Master 或 其 他 任 
何 节 点 上 通过 运行 kubectl proxy 进 程 启动 一 个 内 部 代理 来 实现 。 


运行 下 面 的 命令 ， 我 们 在 8001 端 口 启 动 代 理 ， 并 且 拒 绝 客户 端 访问 
RC 的 API: 


# kubectl proxy --reject-paths="4/api/vi/replicationcon 


Starting to serve on 127.0.0.1:8001 


运行 下 面 的 命令 进行 验证 : 


# curl localhost:8001/api/vi/replicationcontrollers 


<h3>Unauthorized</h3> 


kubectl Proxy 具有 很 多 特性 ， 最 实用 的 一 个 特性 是 提供 简单 有 效 的 
安全 机 制 ， 比 如 采用 白 名 单 来 限制 非法 客户 端 访 问 时 ， 只 要 增加 下 面 这 
个 参数 即 可 : 


--accept -hosts="4localhost$, 4127\\.O\\.O\\.1$, 4\\ [02 :2\\]: 


最 后 一 种 方式 是 通过 编程 的 方式 调用 Kubernetes API Server. H4% 
使 用 场景 又 细 分 为 以 下 两 种 。 


第 1 种 使 用 场景 : 运行 在 Pod 里 的 用 户 进程 调用 Kubernetes API, if 
第 用 来 实现 分 布 式 集群 搭建 的 目标 。 比 如 下 面 这 段 来 自 谷 歌 官方 的 
Elastic Search 集 群 例 子 中 的 代码 ，Pod 在 启动 的 过 程 中 通过 访问 
Endpoints 的 API， 找 到 属于 elasticsearch-logging 这 个 Service 的 所 有 Pod 副 
本 的 IP 地 址 ， 用 来 构建 集群 ， 如 图 3.1 所 示 。 





lastic = nil { 

glog.Warningf("Failed to find the elasticsearch-logging service: %v", err) 

return 
} 

AES A) ER BR HR A E th Ak A Sk fi 
d ts *api.End t 
R > 并 输出 到 控 和 制 台 ， 随 后 被 de 
dd J]string{} 1 
配置 文件 时 
nt : 

for t := time.Now(); time.S EEG 5*time.Minute; time.Sleep(10 + time.Second) { 2 

endpoints, err = c.Endpoints(api.NamespaceSystem) .Get("elasticsearch-logging") 

é nil { 

continue 

addrs = flattenSubsets(endpoints.Subsets) glog-Infof("Endpoints = %s", addrs) 

pe Fran fmt .Printf("discovery.zen.ping.unicast.hosts: [Xs]\n", strings. Join(addrs 

glog.Infof("Found %s", addrs) 

en(addrs) > @ && len(addrs) == count 
break 来 自 镜像 中 的 容器 启动 脚本 
ER: -true} 

count = len(addrs) 

} rn discovery >> /elasticsearch-1.5.2/config/elastics 





图 3.1 ”应 用 程序 编程 访问 API Server 


在 上 述 使 用 场景 中 ，Pod 中 的 进程 如 何 知道 API Server 的 访问 地 址 


We? 答案 很 简单 ， 因 为 Kubernetes API Server 本 身 也 是 一 个 Service， 它 
的 名 字 就 是 “kubernetes”， 并 且 它 的 Cluster IP 地 址 是 Cluster IP 地 址 池 里 
的 第 1 个 地 址 ! 另外 ， 它 所 服务 的 端口 是 HTTPS 端 口 443， 通 过 kubect 
get service 命令 可 以 确认 这 一 点 : 


# kubectl get service 
NAME CLUSTER- IP EXTERNAL - IP PORT(S) 


kubernetes 169.169.0.1 <none> 443/TCP 


第 2 种 使 用 场景 : 开发 基于 Kubernetes 的 管理 平台 。 比 如 调用 
Kubernetes “API 来 完成 Pod、Service、RC 等 资源 对 象 的 图 形 化 创建 和 管 
理 界 面 ， 此 时 可 以 使 用 Kubernetes 及 各 开源 社区 为 开发 人 员 提 供 的 各 种 
语言 版 本 的 Client Library。 我 们 会 在 后 面 介 绍 通过 编程 方式 访问 API 
Server 的 一 些 细节 技术 。 


3.1.2 ”独特 的 Kubernetes Proxy API 接 口 


前 面 我 们 说 过 ，Kubernetes API Server 最 主要 的 REST 接 口 是 资 源 对 
象 的 增 、 删 、 改 、 查 ， 除 此 之 外 ， 它 还 提供 了 一 类 很 特殊 的 REST 接 口 
Kubernetes Proxy API 接 口 ， 这 类 接口 的 作用 是 代理 REST 请 求 ， 即 
Kubernetes API Server 把 收 到 的 REST 请 求 转发 到 某 个 Node 上 的 kubelet 守 
护 进 程 的 REST 端 口上 ， 由 该 Kubelet 进 程 负责 啊 应 。 





首先 ， 我 们 来 说 说 Kubernetes Proxy API 里 关于 Node 的 相关 接口 ， 
该 接口 的 REST 路 径 为 /api/v1/proxy/nodes/{name}， 其 中 {name} 为 节点 的 
名 称 或 IP 地 址 ， 包 括 以 下 几 个 具体 接口 : 





e /api/v1/proxy/nodes/{name}/pods/ ”# 列 出 指定 节点 内 所 有 Pod 的 信息 

e /api/v1/proxy/nodes/{name}/stats/”# 列 出 指定 节点 内 物理 资源 的 统 
计 信 息 

e /api/v1/proxy/nodes/{name}/spec/ ”# 列 出 指定 节点 的 概要 信息 


例如 当前 Node 节 点 的 名 字 为 k8s-node-1， 用 下 面 的 命令 即 可 获取 该 
节点 上 所 有 运行 中 的 Pod: 


# curl localhost:8080/api/v1/proxy/nodes/k8s-node-1/pods 


需要 说 明 的 是 : 这 里 获取 的 Pod 的 信息 数据 来 自 Node 而 非 etcd 数 据 
库 ， 所 以 两 者 可 能 在 某 些 时 间 点 会 有 偏差 。 此 外 ， 如 果 kubelet 进 程 在 启 
动 时 包含 --enable-debugging-handlers=true 参 数 ， 那 么 Kubernetes Proxy 
API 还 会 增加 下 面 的 接口 : 








e /api/v1/proxy/nodes/{name}/run # 在 节点 上 运行 某 个 容器 


e /api/v1/proxy/nodes/{name}/exec # 在 节点 上 的 某 个 容 右 中 运行 
ERMS 


e /api/v1/proxy/nodes/{name}/attach ”# 人 在 节点 上 attach 某 个 容 
器 /api/v1/proxy/nodes/{name}/portForward # 实 现 节 点 上 的 Pod 端 口 
转发 

e /api/v1/proxy/nodes/{name }/logs # 列 出 节点 的 各 类 日 志 信息 ， 
例如 tallylog、lastlog、wtmp、ppp/、rhsm/、audit/、 ee 
anaconda/ 等 


e /api/v1/proxy/nodes/{name}/metrics # 列 出 和 该 节点 相关 的 Metrics 信 
自 


e /api/v1/proxy/nodes/{name}/runningpods  # 列 出 节点 内 运行 中 的 Pod 
兰 自 
H 4 


e /api/vl/proxy/nodes/{namej/debug/pprof# 列 出 节点 内 当前 Web 服 务 的 
状态 ， 包 括 CPU 占用 情况 和 内 存 使 用 情况 等 


Eo 我 们 来 说 说 Kubernetes Proxy API 里 关于 Pod 的 相关 接口 ， 
这 些 接 口 ， 我 们 可 以 访问 Pod 里 某 个 容器 提供 的 服务 (如 Tomcat 在 
口服 务 〉: 


e /api/v1/proxy/namespaces/{namespace}/pods/{name}/{path: *}# 访 问 
Pod 的 某 个 服务 接口 

e /api/v1/proxy/namespaces/{namespace}/pods/{name} # 访 问 Pod 

e /api/v1/namespaces/{namespace}/pods/{name}/proxy/{path: *}# 访 问 
Pod 的 茶 个 服务 接口 

e /api/v1/namespaces/{namespace}/pods/{name}/proxy # 访 问 Pod 


在 上 面 的 4 个 接口 里 ， 后 面 两 个 接口 的 功能 与 前 面 两 个 完全 一 样 ， 





只 是 写法 不 同 。 下 面 我 们 用 第 1 章 的 Java Web 例子 中 的 Tomcat Pod 来 说 
明 上 述 Proxy 接 口 的 用 法 。 


首先 ， 得 到 Pod 的 名 字 : 


# kubectl get pods 


NAME READY STATUS RESTARTS AGE 
mysql-c95jc 1/1 Running 0 8d 
myweb-g9pmm 1/1 Running 0 8d 


然后 ， 运 行 下 面 的 命令 ， 会 输出 Tomcat 的 首页 ， 即 相当 于 访问 
http://localhost: 8080/: 


# curl http://localhost:8080/api/vi/proxy/namespaces/derf. 


我 们 也 可 以 在 浏览 器 中 访问 上 面 的 地 址 ， 比 如 Master 市 点 的 IP 地 址 
是 192.168.18.131， 我 们 在 浏览 器 中 输入 http://192.168.18.131: 
8080/api/v1/proxy/namespaces/default/pods/myweb-g9pmm/， 就 能 够 访问 
Tomcat 首 页 了 ; 而 如 果 输 
入 /api/vLproxy/namespaces/defaultpods/myweb-g9pmmy/demo， 就 能 访问 
Tomcat 中 Demo 应 用 的 页 面 了 。 


看 到 这 里 ， 你 可 能 明白 Pod 的 Proxy 接 口 的 作用 和 意义 了 : 在 
Kubernetes 集 群 之 外 访问 某 个 Pod 容 器 的 服务 (HTTP 服务 ) 时 ， 可 以 用 
Proxy _ API 实现， 这 种 场景 多 用 于 管理 目的 ， 比 如 逐一 排查 Service 的 Pod 
副本 ， 检 查 哪些 Pod 的 服务 存在 异常 问题 。 





最 后 我 们 说 说 Service，Kubernetes Proxy API 也 有 Service 的 Proxy 接 


口 ， 其 接口 定义 与 Pod 的 接口 定义 基本 一 

样 : /api/v1/proxy/namespaces/{namespace}/services/{name}。 比 如 ， 我 们 
想 访问 myweb 这 个 Service， 则 可 以 在 浏览 器 里 输入 
http://192.168.18.131: 
8080/api/v1/proxy/namespaces/default/services/myweb/demo/. 


3.1.3 ”集群 功能 模块 之 间 的 通信 


从 图 3.2 中 可 以 看 出 ，KubernetesAPI Server 作 为 集群 的 核心 ， 负 责 
集群 各 功能 模块 之 间 的 通信 。 集 群 内 的 各 个 功能 模块 通过 API Server 将 
言 轧 存 入 etcd， 当 需要 获取 和 操作 这 些 数 据 时 ， 则 通过 API Server 提 供 的 
REST 接 口 〈 用 GET、LIST 或 WATCH 方 法 ) 来 实现 ， 从 而 实现 各 模块 之 
间 的 信息 交互 





常见 的 一 个 交互 场景 是 kubelet 进 程 与 API Server 的 交互 。 每 个 Node 
节点 上 的 kubelet 每 隅 一 个 时 间 周 期 ， 就 会 调用 一 次 API Server 的 REST 接 
口 报告 自 身 状 态 ，API Server 接 收 到 这 些 信息 后 ， 将 节点 状态 信息 更 新 
到 etcd 中 。 此 外 ，kubelet 也 通过 API ， Server 的 Watch 接口 监听 Pod 信 息 ， 
如 果 监 听 到 新 的 Pod 副 本 被 调度 绑 定 到 本 节点 ， 则 执行 Pod 对 应 的 容器 的 
创建 和 启动 逻辑 ， 如果 监 昕 到 Pod 对 象 被 删除 ， 则 删除 本 节点 上 的 相应 
的 Pod 容 器 ; 如 果 监 昕 到 修改 Pod 信 息 ， 则 kubelet 监 昕 到 变化 后 ， 会 相应 
地 修改 本 节点 的 Pod 容 器 。 

















Á f Master 














图 3.2 ”Kubernetes 结 构图 


另外 一 个 交互 场景 是 kube-controller-manager 进 程 与 API Server 的 交 
互 。kube-controller-manager 中 的 Node Controller 模 块 通过 API Sever 提 供 
的 Watch 接口 ， 实 时 监控 Node 的 信息 ， 并 做 相应 处 理 。 


还 有 一 个 比较 重要 的 交互 场景 是 kube-scheduler 与 API ” Server 的 交 
互 。 当 Scheduler 通 过 API Server 的 Watch 接口 监听 到 新 建 Pod 副 本 的 信息 
后 ， 它 会 检索 所 有 符合 该 Pod 要 求 的 Node 列 表 ， 开 始 执 行 Pod 调 度 逻 
辑 ， 调 度 成 功 后 将 Pod 绑 定 到 目标 节点 上 。 


为 了 缓解 集群 各 模块 对 API Server 的 访问 压力 ， 各 功能 模块 都 采用 
绥 存 机 制 来 缓存 数据 。 各 功能 模块 定时 从 API Server 获 取 指 定 的 资源 对 
象 信 息 《〈 通 过 LIST 及 WATCH 方 法 ) ， 然 后 将 这 些 信 息 保 存 到 本 地 组 
存 ， 功 能 模块 在 某 些 情况 下 不 直接 访问 API Server， 而 是 通过 访问 绥 存 
数据 来 间接 访问 API Server。 








3.2 Controller Manager 原 理 分 析 


Controller ”Manager 作 为 集群 内 部 的 管理 控制 中 心 ， 负 责 集 群 内 的 
Node、Pod 副 本 、 服 务 端点 (Endpoint) 、 命 名 空间 (Namespace) 、 服 
务 账号 〈ServiceAccount) 、 资 源 定 额 (ResourceQuota) 等 的 管理 ， 当 
某 个 Node 意 外 宕 机 时 ，Controller Manager 会 及 时 发 现 此 故障 并 执行 自动 
化 修复 流程 ， 确 保 集群 始终 处 于 预期 的 工作 状态 。 


如 图 3.3 所 示 ，Controller Manager 内 部 包含 Replication Controller、 
Node Controller, ResourceQuota Controller, Namespace Controller, 
ServiceAccount Controller, Token Controller, Service Controller 
Endpoint “ “Controller 等 多 个 Controller， 每 种 Controller 都 负责 一 种 具体 的 
控制 流程 ， 而 Controller Manager 正 是 这 些 Controller 的 核心 管理 者 。 
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图 3.3 Controller Manager 结 构图 


一 般 来 说， 智能 系统 和 自动 系统 通常 会 通过 一 个 被 称 为 “操纵 系 
统 ” 的 机 构 来 不 断 修 正 系统 的 工作 状态 。 在 Kubernetes 集 群 中 ， 每 个 
Controller 都 是 这 样 一 个 “操纵 系统 ”， 它 们 通过 API Server 提 供 的 接口 实 
时 监控 整个 集群 里 的 每 个 资源 对 象 的 当前 状态 ， 当 发 生 各 种 故障 导致 系 
统 状态 发 生变 化 时 ， 会 尝试 着 将 系统 状态 从 * 现 有 状态 ”修正 到 “期 望 状 
态 ”。 本 节 将 详细 分 析 Controller Manager 的 这 些 Controller 的 原理 。 





由 于 ServiceAccount Controller 与 Token Controller 是 与 安全 相关 的 两 
个 控制 器 ， 并 且 与 Service Account、Token 密 切 相 关 ， 所 以 我 们 将 对 它们 
的 分 析 放 到 后 面 的 深入 集群 安全 的 章节 中 讲解 。 


在 Kubernetes 集 群 中 与 Controller Manager 并 重 的 男 一 个 组 件 是 
Kubernetes Scheduler， 它 的 作用 是 将 待 调度 的 Pod〈 包 括 通过 API Server 
新 创建 的 Pod 及 RC 为 补足 副本 而 创建 的 Pod 等 ) 通过 一 些 复杂 的 调度 流 
程 计 算出 最 佳 目标 节点 ， 然 后 绑 定 到 该 节点 上 。 本 章 最 后 会 介绍 
Kubernetes Scheduler 调 度 器 的 基本 原理 。 














3.2.1 ReplicationController 


为 了 区 分 Controller Manager 中 的 Replication Controller (副本 控制 
器 ) 和 资源 对 象 Replication Controller， 我 们 将 资源 对 象 Replication 
Controller 简 写 为 RC， 而 本 节 中 的 Replication ”Controller 是 指 “ 副 本 控制 
器 ”， 以 便于 后 续 分 析 。 


Replication ” Controller 的 核心 作用 是 确保 在 任何 时 候 集 群 中 一 个 RC 

所 关联 的 Pod 副 本 数量 保持 预 设 值 。 如 果 发 现 Pod 副 本 数量 超过 预期 值 ， 
则 Replication Controller 会 销毁 一 些 Pod 副 本 ; 反之 ，Replication 
Controller 会 自动 创建 新 的 Pod 副 本 ， 直 到 符合 条 件 的 Pod 副 本 数量 达到 
预 设 值 。 需 要 注意 的 一 点 是 : 只 有 当 Pod 的 重启 策略 是 Always 的 时 候 

(RestartPolicy=Always) ，Replication Controller 才 会 管理 该 Pod 的 操作 

《例如 创建 、 销 毁 、 重 启 等 )。 在 通常 情况 下 ，Pod 对 象 被 成 功 创建 后 
不 会 消失 ， 唯 一 的 例外 是 当 Pod 处 于 succeeded 或 failed 状 态 的 时 间 过 长 

(超时 参数 由 系统 设 定 ) 时 ， 访 Pod 会 被 系统 自动 回收 ， 管 理 该 Pod 的 副 
本 控制 器 将 在 其 他 工作 节点 上 重新 创建 、 运 行 该 Pod 副 本 。 











RC 中 的 Pod 模 板 就 像 一 个 模具 ， 模 具 制 作出 来 的 东西 一 旦 离开 模 
具 ， 它 们 之 间 就 再 也 没关系 了 。 同 样 ， 一 旦 Pod 被 创建 完毕 ， 无 论 模板 
如 何 变化 ， 甚 至 换 成 一 个 新 的 模板 ， 也 不 会 影响 到 已 经 创建 的 pod。 此 
外 ，Pod 可 以 通过 修改 它 的 标签 来 实现 脱离 RC 的 管控 。 该 方法 可 以 用 于 
将 Pod 从 集群 中 迁移 、 数 据 修 复 等 调试 。 对 于 被 迁移 的 Pod 副 本 ，RC 会 
自动 创建 一 个 新 的 副本 蔡 换 被 迁移 的 副本 。 需 要 注意 的 是 ， 删 除 一 个 
RC 不 会 影响 它 所 创建 的 Pod。 如 果 想 删除 一 个 RC 所 控制 的 Pod， 则 需要 


将 该 RC 的 副本 数 (Replicas) 属性 设置 为 0， 这 样 所 有 的 Pod 副 本 都 会 被 
自动 删除 。 


我 们 最 好 不 要 越过 RC 而 直接 创建 Pod， 因 为 Replication Controller 会 
通过 RC 管 理 Pod 副 本 ， 实 现 自动 创建 、 补 足 、 蔡 换 、 删 除 Pod 副 本 ， 这 
样 能 提高 系统 的 容 灾 能 力 ， 减 少 由 于 节点 崩 尝 等 意外 状况 造成 的 损失 。 
即使 你 的 应 用 程序 只 用 到 一 个 Pod 副 本 ， 我 们 也 强烈 建议 使 用 RC 来 定义 
Pod. 





我 们 总 结 一 下 Replication Controller 的 职责 ， 如 下 所 述 。 


(1) 确保 当前 集群 中 有 且 仅 有 N 个 Pod 实 例 ，N 是 RC 中 定义 的 Pod 
副本 数量 。 


(2) 通过 调整 RC 的 spec.replicas 属 性 值 来 实现 系统 扩容 或 者 缩 容 。 
(3) 通过 改变 RC 中 的 Pod 模 板 〈( 主 要 是 镜像 版 本 ) 来 实现 系统 的 
滚动 升级 。 


最 后 ， 我 们 总 结 一 下 Replication Controller 的 典型 使 用 场景 ， 如 下 所 

(1) 重新 调度 (Rescheduling) 。 如 前 面 所 提 及 的 ， 不 管 你 想 运行 
1 个 副本 还 是 1000 个 副本 ， 副 本 控制 器 都 能 确保 指定 数量 的 副本 存在 于 
集群 中 ， 即 使 发 生 节 点 故障 或 Pod 副 本 被 终止 运行 等 意外 状况 。 





(2) 弹性 伸缩 (Scaling〉。 手 动 或 者 通过 自动 扩容 代理 修改 副本 
控制 器 的 spec.replicas 属 性 值 ， 非 党 容易 实现 扩大 或 缩小 副本 的 数量 。 





(3) 滚动 更 新 (Rolling Updates) 。 副 本 控制 器 被 设计 成 通过 逐个 


替换 Pod 的 方式 来 辅助 服务 的 滚动 更 新 。 推 荐 的 方式 是 创建 一 个 新 的 只 
有 一 个 副本 的 RC， 若 新 的 RC 副本 数量 加 1， 则 旧 的 RC 的 副本 数量 减 1， 
直到 这 个 旧 的 RC 的 副本 数量 为 零 ， 然 后 删除 该 旧 的 RC。 通 过 上 述 模 
式 ， 即 使 在 滚动 更 新 的 过 程 中 发 生 了 不 可 预料 的 错误 ，Pod 集 合 的 更 新 
也 都 在 可 控 范 围 内 。 在 理想 情况 下 ， 滚 动 更 新 控制 器 需要 将 准备 就 绪 的 
应 用 考虑 在 内 ， 并 保证 在 集群 中 任何 时 刻 都 有 足够 数量 的 可 用 Pod。 





3.2.2 NodeControljer 





kubelet 进 程 在 启动 时 通过 API Server 注 册 自 身 的 节点 信息 ， 并 定时 
问 API Server 汇 报 状 态 信息 ，API Servex 接 收 到 这 些 信息 后 ， 将 这 些 信息 
更 新 到 etcd 中 ，etcd 中 存储 的 节点 信息 包括 节点 健康 状况 、 节 点 资源 、 
节点 名 称 、 节 点 地 址 信息 、 操 作 系 统 版 本 、Docker 版 本 、kubelet 版 本 
节点 健康 状况 包 售 “ 就 结 ” (True) “AWA” (False) FUCA 
4” (Unknown) =F}. 


Node Controller 通 过 API Server 实 时 获取 Node 的 相关 信息 ， 实 现 管理 
和 监控 集群 中 的 各 个 Node 节 点 的 相关 控制 功能 ，NodeController 的 核心 
工作 流程 如 图 3.4 所 示 。 


如 果 Controller Manager 设 置 了 


“一 cluster-cidr” 参 数 ， 则 为 每 
个 Node 配 置 “Spec.PodCIDR” 


逐个 读 取 Node 信 息 ， 并 和 本 
地 nodeStatusMap 做 比较 






没有 收 到 节点 信息 或 第 一 次 收 ' 
到 节点 信息 ， 或 在 该 处 理 过 各 人 


点 信息 ， 但 节点 状态 没 发 
iar aa 健康 ” 且 节 点 状 : 
ae 变化 生变 化 


用 Master 节 点 的 系统 时 间作 用 Master 节 点 的 系统 时 间作 用 Master 节 点 的 系统 时 间作 为 探测 时 
为 探测 时 间 和 节点 状态 变化 为 探测 时 间 和 节点 状态 变化 E, 用 上 次 节点 信息 中 的 节点 状态 变 
时 间 时 间 化 时 间作 为 该 节点 的 状态 变化 时 间 


如 果 在 某 一 gh dr a 
态 信 息 ， 则 设置 节点 状态 为 “ 


删除 节点 或 同步 
节点 信息 


图 3.4 Node Controller 流 程 图 


对 流程 中 关键 点 的 解释 如 下 。 


(1) Controller Manager 在 启动 时 如 果 设 置 了 --cluster-cidr 参 数 ， 那 
么 为 每 个 没有 设置 Spec.PodCIDR 的 Node 节 点 生成 一 个 CIDR 地 址 ， 并 用 
该 CIDR 地 址 设置 节点 的 Spec.PodCIDR 属 性 ， 这 样 做 的 目的 是 防止 不 同 
节点 的 CIDR 地 址 发 生 冲突 。 





(2) 逐个 读 取 节点 信息 ， 多 次 尝试 修改 nodeStatusMap 中 的 节点 状 
态 信 息 ， 将 该 节点 信息 和 Node Controller 的 nodeStatusMap 中 保存 的 节点 
言 息 做 比较 。 如 果 判 断 出 没有 收 到 kubelet 发 送 的 节点 信息 、 第 1 次 收 到 
节点 kubelet 发 送 的 节点 信息 ， 或 在 该 处 理 过 程 中 节点 状态 变 成 非 “ 健 
康 ” 状 态 ， 则 在 nodeStatusMap 中 保存 该 节点 的 状态 信息 ， 并 用 Node 
Controller 所 在 节点 的 系统 时 间作 为 探测 时 间 和 节点 状态 变化 时 间 。 如 果 
判断 出 在 指定 时 间 内 收 到 新 的 节点 信息 ， 且 市 点 状态 发 生变 化 ， 则 在 
nodeStatusMap 中 保存 该 节点 的 状态 信息 ， 并 用 Node Controller 所 在 节点 
的 系统 时 间作 为 探测 时 间 和 节点 状态 变化 时 间 。 如 果 判 断 出 在 指定 时 间 
内 收 到 新 的 节点 信息 ， 但 节点 状态 没 发 生变 化 ， 则 在 nodeStatusMap 中 
保存 该 节点 的 状态 信息 ， 并 用 Node Controller 所 在 节点 的 系统 时 间作 为 
探测 时 间 ， 用 上 次 节点 信息 中 的 节点 状态 变化 时 间作 为 该 节点 的 状态 变 
化 时 间 。 如 果 判 断 出 在 某 一段 时 间 〈gracePeriod) 内 没有 收 到 节点 状态 
信息 ， 则 设置 节点 状态 为 未知”(Unknown) ， 并 且 通 过 API Server 保 
存 节点 状态 。 





























(3) 逐个 读 取 节点 信息 ， 如 末节 点 状态 变 为 非 * 就 绪 ? 状 态 ， 则 将 
节 点 加 入 待 删除 队列 ， 和 否则 将 节点 从 该 队列 中 删除 。 如 果 节 点 状态 为 
非 “ 就 绪 ” 状 态 ， 且 系统 指定 了 Cloud Provider, JlllNode Controller 调 用 
Cloud Provider 碍 看 节点 ， 奋 发 现 节点 故障 ， 则 删除 etcd 中 的 节点 信息 ， 
并 删除 和 该 节点 相关 的 Pod 等 资源 的 信息 。 





3.2.3 ResourceQuotaController 


作为 完备 的 企业 级 的 容器 集群 管理 平台 ，Kubernetes 也 提供 了 资源 
配额 管理 (ResourceQuota Controller) 这 一 高 级 功能 ， 资 源 配 额 管理 确 
保 了 指定 的 资源 对 象 在 任何 时 候 都 不 会 超 量 占用 系统 物理 资源 ， 避 免 了 
由 于 某 些 业务 进程 的 设计 或 实现 的 缺陷 导致 整个 系统 运行 紊乱 甚至 意外 
宕 机 ， 对 整个 集群 的 平稳 运行 和 稳定 性 有 非常 重要 的 作用 。 











目前 Kubernetes 文 持 如 下 三 个 层次 的 资源 配额 管理 。 
(1) 容器 级 别 ， 可 以 对 CPU 和 Memory 进 行 限制 。 
(2) Pod 级 别 ， 可 以 对 一 个 Pod 内 所 有 容器 的 可 用 资源 进行 限制 。 


(3) Namespace 级 别 ， 为 Namespace (多 租户 ) 级 别 的 资源 限制 ， 
包括 : 


e Pod 数 量 ; 


ReplicationController 数 量 ; 


e Service 数 量 ; 
e ResourceQuota 数 量 ; 
Secret Œ; 


可 持 有 的 PV (Persistent Volume) 数量 。 


Kubernetes 的 配额 管理 是 通过 Admission Control ( 准 入 控制 ) 来 控制 
的 ，Admission Control 当 前 提供 了 两 种 方式 的 配额 约束 ， 分 别 是 


LimitRanger 与 ResourceQuota。 其 中 LimitRanger 作 用 于 Pod 和 Container 
上 ， 而 ResourceQuota 则 作用 于 Namespace 上， 限定 一 个 Namespace 里 的 
各 类 资源 的 使 用 总 额 。 








如 图 3.5 所 示 ， 如 果 在 Pod 定 义 中 同时 声明 了 LimitRanger， 则 用 户 通 
WAPI Server 请 求 创建 或 修改 资源 时 ，Admission Control 会 计算 当前 配额 
的 使 用 情况 ， 如 果 不 符合 配额 约束 ， 则 创建 对 象 失败 。 对 于 定义 了 
ResourceQuota 的 Namespace，ResourceQuota ”Controller 组 件 则 负责 定期 
统计 和 生成 该 Namespace 下 的 各 类 对 象 的 资源 使 用 总 量 ， 统 计 结 果 包 括 
Pod, Service. RC. Secret 和 Persistent Volume 等 对 象 实 例 个 数 ， 以 及 该 
Namespace 下 所 有 Container 实 例 所 使 用 的 资源 量 〈( 目 前 包括 CPU 和 内 
存 ) ， 然 后 将 这 些 统计 结果 写 入 etcd 的 resourceQuotaStatusStorage 目 录 

(resourceQuotas/status) 中 。 写 入 resourceQuotaStatusStorage 的 内 容 包含 
Resource 名 称 、 配 额 值 (ResourceQuota 对 象 中 spec.hard 域 下 包含 的 资源 
的 值 ) 、 当 前 使 用 值 (ResourceQuota ” Controller 统 计 出 来 的 值 ) 。 随 后 
这 些 统计 信息 被 Admission Control 使 用 ， 以 确保 相关 Namespace 下 的 资 
源 配 额 总 量 不 会 超过 ResourceQuota 中 的 限定 值 。 
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同时 统计 这 些 资源 ， 
并 将 结果 写 入 etcd 
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图 3.5 ResourceQuota Controller 流 程 图 


3.2.4 NamespaceController 


用 户 通过 API Server 可 以 创建 新 的 Namespace 并 保存 在 etcd 中 ， 
Namespace Controller 定 时 通过 API Server 读 取 这 些 Namespace 人 信息。 如果 
Namespace 被 API 标 识 为 优雅 删除 〈 通 过 设置 删除 期 限 ， 即 
DeletionTimestamp 属 性 被 设置 ) ， 则 将 该 NameSpace 的 状态 设置 
成 “Terminating” 并 保存 到 etcd 中 。 同 时 Namespace Controller 删 除 该 
Namespace 下 的 ServiceAccount、RC、Pod、Secret、PersistentVolume、 
ListRange、ResourceQuota 和 Event 等 资源 对 象 。 


当 Namespace 的 状态 被 设置 成 “Terminating” 后 ， 由 Admission 
Controller 的 NamespaceLifecycle 插 件 来 阻止 为 该 Namespace 创 建新 的 资 
源 。 同 时 ， 在 Namespace Controller 删 除 完 该 Namespace 中 的 所 有 资源 对 
象 后 ，Namespace Controller 对 该 Namespace 执 行 finalize 操 作 ， 删 除 
Namespace 的 spec.finalizers 域 中 的 信息 。 


如 果 Namespace Controller 观 察 人 到 Namespace 设 置 了 删除 期 限 ， 同 时 
Namespace 的 spec.finalizers 域 值 是 空 的 ， 那 么 Namespace ”Controller 将 通 
WAPI Server 删 除 该 Namespace 资 源 。 


3.2.5 Service Controller- Endpoint Controller 


我 们 先 说 说 Endpoints Controller， 在 这 之 前 ， 让 我 们 先 看 看 
Service、Endpoints 与 Pod 的 关系 ， 如 图 3.6 所 示 ，Endpoints 表 示 了 一 个 
Service 对 应 的 所 有 Pod 副 本 的 访问 地 址 ， 而 Endpoints Controller 就 是 负责 
生成 和 维护 所 有 Endpoints 对 象 的 控制 器 。 
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图 3.6 ”Service、Endpoint、Pod 的 关系 





它 负 责 监 听 Service 和 对 应 的 Pod 副 本 的 变化 ， 如 果 监 测 到 Service 被 
删除 ， 则 删除 和 该 Service 同 名 的 Endpoints 对 象 ， 如 果 监 测 到 新 的 Service 
被 创建 或 者 修改 ， 则 根据 该 Service 信 息 获 得 相关 的 Pod 列 表 ， 然 后 创建 
或 者 更 新 Service 对 应 的 Endpoints 对 象 。 如 采 监 测 到 Pod 的 事件 ， 则 更 新 
它 所 对 应 的 Service 的 Endpoints 对 象 〈 增 加 、 删 除 或 者 修改 对 应 的 


Endpoint 条 目 ) 。 





那么 ，Endpoints 对 象 是 在 哪里 被 使 用 的 呢 ? 答案 是 每 个 Node 上 的 
kube-proxy 进 程 ，kube-proxy 进 程 获取 每 个 Service 的 Endpoints， 实 现 了 
Service 的 负载 均衡 功能 。 在 后 面 的 章节 中 我 们 会 深入 讲解 这 部 分 内 容 。 


接 下 来 我 们 说 说 Service Controller 的 作用 ， 它 其 实 是 属于 Kubernetes 
集群 与 外 部 的 云 平台 之 间 的 一 个 接口 控制 器 。Service Controllers Yr 
Service 的 变化 ， 如 果 是 一 个 LoadBalancer 类 型 的 
Service (externalLoadBalancers=true) ， 则 Service Controller 确 保 外 部 的 
云 平 台 上 该 Service 对 应 的 LoadBalancer 实 例 被 相应 地 创建 、 删 除 及 更 新 
路 由 转发 表 〈 根 据 Endpoints 的 条 目 ) 。 








3.3 ”Scheduler 原 理 分 析 


我 们 在 前 面 深入 分 析 了 Controller Manager 及 它 所 包含 的 各 个 组 件 的 
运行 机 制 。 本 节 我 们 将 继续 对 Kubernetes 中 负责 Pod 调 度 的 重要 功能 模块 
Kubernetes Scheduler 的 工作 原理 和 运行 机 制 做 深入 分 析 。 





Kubernetes Scheduler 在 整个 系统 中 承担 了 “承上启下 ”的 重要 功 
能 ,“ 承 上? 是 指 它 负 责 接收 Controller Manager 创 建 的 新 Pod， 为 其 安排 
一 个 落脚 的 “家 ?” 目标 Node; “局 下 ?是 指 安置 工作 完成 后 ， 目 标 Node 
上 的 kubelet 服 务 进程 接管 后 继 工 作 ， 负 责 Pod 生 命 周 期 中 的 “下 半生 ”。 














具体 来 说 ，Kubernetes Scheduler 的 作用 是 将 待 调度 的 Pod (APIKE 
建 的 Pod、Controller Manager 为 补足 副本 而 创建 的 Pod 等 ) 按照 特定 的 调 
度 算 法 和 调度 策略 绑 定 《Binding) 到 集群 中 的 某 个 合适 的 Node 上 ， 并 
将 绑 定 信息 写 入 etcd 中 。 在 整个 调度 过 程 中 涉及 三 个 对 象 ， 分 别 是 : 行 
调度 Pod 列 表 、 可 用 Node 列 表 ， 以 及 调度 算法 和 策略 。 人 简单 地 说 ， 就 是 
通过 调度 算法 调度 为 竺 调度 Pod 列 表 的 每 个 pod 从 Node 列 表 中 选择 一 个 
最 适合 的 Node。 


随后 ， 目 标 节 点 上 的 kubelet 通 过 API Server 监 听 到 Kubernetes 
Scheduler 产 生 的 Pod 绑 定 事 件 ， 然 后 获取 对 应 的 Pod 清 单 ， 下 载 Image 镜 
像 ， 并 局 动容 器。 完整 的 流程 如 图 3.7 所 示 。 
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3.7 Scheduler ýE 
Kubernetes Scheduler 当 前 提供 的 默认 调度 流程 分 为 以 下 两 步 。 


(1) 预选 调度 过 程 ， 即 届 历 所 有 目标 Node， 和 筛选 出 符合 要 求 的 候 
选 节 点 。 为 此 ，Kubernetes 内 置 了 多 种 预选 策略 (xxx Predicates) 供用 
户 选 择 。 





(2) 确定 最 优 节点 ， 在 第 1 步 的 基础 上 ， 采 用 优选 策略 (xxx 
Priority) 计算 出 每 个 候选 节点 的 积分 ， 积 分 最 高 者 胜出 。 


Kubernetes ”Scheduler 的 调度 流程 是 通过 插件 方式 加 载 的 “调度 算法 
提供 者 ”(AlgorithmProvider〉 具体 实现 的 。 一 个 AlgorithmProvider 其 实 
就 是 包括 了 一 组 预选 策略 与 一 组 优先 选择 策略 的 结构 体 ， 注 册 
AlgorithmProvider 的 函数 如 下 : 


func RegisterAlgorithmProvider(name String，predicateKey': 


它 包 含 三 个 参数 : “name string” 参 数 为 算法 名 ; “predicateKeys” 参 数 


为 算法 用 到 的 预选 策略 集合 ; “priorityKeys” 为 算法 用 到 的 优选 策略 集 


A 
O o 


Scheduler 中 可 用 的 预选 策略 包含 : NoDiskConflict、 
PodFitsResources 、PodSelectorMatches、PodFitsHost、 
CheckNodeLabelPresence、CheckServiceAffinity 和 PodFitsPorts 策 略 等 。 
其 默认 的 AlgorithmProvider 加 载 的 预选 策略 Predicates 包 括 : 

PodFitsPorts (PodFitsPorts) 、PodFitsResources (PodFitsResources) 、 
NoDiskConflict (NoDiskConflict) 、 

MatchNodeSelector (PodSelectorMatches) 和 

HostName (PodFitsHost) ， 即 每 个 节点 只 有 通过 前 面 提 及 的 5 个 默认 预 
选 策 略 后 ， 才 能 初步 被 选中 ， 进 入 下 一 个 流程 。 








下 面 列 出 的 是 对 所 有 预选 策略 的 详细 说 明 。 
1) NoDiskConflict 


判断 备 选 Pod 的 GCEPersistentDisk 或 AWSElasticBlockStore 和 备 选 的 
节点 中 已 存在 的 Pod 是 否 存在 冲突 。 检 测 过 程 如 下 。 








(1) 首先 ， 读 取 备 选 Pod 的 所 有 Volume 的 信息 《〈 即 
pod.Spec.Volumes) ， 对 每 个 Volume 执 行 以 下 步骤 进行 冲突 检测 。 


(2) 如 果 该 Volume 是 GCEPersistentDisk， 则 将 Volume 和 备 选 节点 
上 的 所 有 Pod 的 每 个 volume 进行 比较 ， 如 果 发 现 相同 的 
GCEPersistentDisk， 则 返回 false， 表 明 存 在 磁盘 冲突 ， 检 查 结束 ， 反 人 馈 
给 调度 器 该 备 选 节点 不 适合 作为 备 选 Pod; 如 果 该 Volume 是 
AWSElasticBlockStore， 则 将 Volume 和 备 选 节点 上 的 所 有 Pod 的 每 个 
Volume 进 行 比较 ， 如 果 发 现 相 同 的 AWSElasticBlockStore， 则 返回 








false， 表 明 存 在 磁盘 冲突 ， 检 查 结束 ， 反 馈 给 调度 器 该 备 选 节点 不 适合 
备 选 Pod。 


(3) 如 果 检 查 完备 选 Pod 的 所 有 Volume 均 未 发 现 冲 突 ， 则 返回 
true， 表 明 不 存在 人 厂 盘 冲突 ， 反 馈 给 调度 器 该 备 选 节点 适合 备 选 Pod。 





2) PodFitsResources 
判断 备 选 节点 的 资源 是 人 否 满足 备 选 Pod 的 需求 ， 检 测 过 程 如 下 。 


(1) 计算 备 选 Pod 和 节点 中 已 存在 Pod 的 所 有 容器 的 需求 资源 〈 内 
存 和 CPU) 的 总 和 。 





(2) 获得 备 选 节点 的 状态 信息 ， 其 中 包含 节点 的 资源 信息 。 


(3) 如 果 备 选 Pod 和 节点 中 己 存 在 Pod 的 所 有 容器 的 需求 资源 (内 
存 和 CPU) 的 总 和 ， 超 出 了 备 选 节点 拥有 的 资源 ， 则 返回 false， 表 明 备 
选 节点 不 适合 备 选 Pod， 和 否则 返回 true， 表 明 备 选 节点 适合 备 选 Pod。 


3) PodSelectorMatches 
判断 备 选 节点 是 否 包 含 备 选 Pod 的 标签 选择 器 指定 的 标签 
(1) 如 果 Pod 没 有 指定 spec.nodeSelector 标 签 选择 器 ， 则 返回 true。 


(2) 否则 ， 获 得 备 选 节点 的 标签 信息 ， 判 断 节 点 是 否 包含 备 选 Pod 
的 标签 选择 器 Cspec.nodeSelector) 所 指定 的 标签 ， 如 果 包 含 ， 则 返回 
true， 奋 则 返回 false。 


4) PodFitsHost 


判断 备 选 Pod 的 specnodeName 域 所 指定 的 节点 名 称 和 备 选 节 氮 的 名 
称 是 否 一 致 ， 如 条 一 致 ， 则 返回 true， 人 否则 返回 false。 


5) CheckNodeLabelPresence 


如 采用 户 在 配置 文件 中 指定 了 该 策略 ， 则 Scheduler 会 通过 
RegisterCustomFitPredicate 方 法 注册 该 策略 。 该 策略 用 于 判断 策略 列 出 
的 标签 在 备 选 节点 中 存在 时 ， 是 否 选择 该 备 选 节点 。 


C1) 读 取 备 选 节点 的 标签 列表 信息 。 





C2) 如 采 策 略 配置 的 标签 列表 存在 于 备 选 节点 的 标签 列表 中 ， 且 
策略 配置 的 presence 值 为 false， 则 返回 false， 人 否则 返回 true; 如 有 条 策略 配 
置 的 标签 列表 不 存在 于 备 选 节点 的 标签 列表 中 ， 且 策略 配置 的 presence 
值 为 tue， 则 返回 false， 和 否则 返回 true。 


6) CheckServiceAffinity 


如 果 用 户 在 配置 文件 中 指定 了 该 策略 ， 则 Scheduler 会 通过 
RegisterCustomFitPredicate 方 法 注册 该 策略 。 该 策略 用 于 判断 备 选 节点 
是 否 包含 策略 指定 的 标签 ， 或 包含 和 备 选 Pod 在 相同 Service 和 Namespace 
下 的 Pod 所 在 节点 的 标签 列表 。 如 果 存 在 ， 则 返回 true， 人 否则 返回 false。 


7) PodFitsPorts 


判断 备 选 Pod 所 用 的 端口 列表 中 的 端口 是 否 在 备 选 节 点 中 已 被 占 
用 ， 如 果 被 占用 ， 则 返回 false， 人 否则 返回 true。 


Scheduler 中 的 优选 策略 包含 : LeastRequestedPriority、 
CalculateNodeLabelPriority 和 了 BalancedResourceAllocation 等 。 每 个 节点 通 





过 优先 选择 策略 时 都 会 算出 一 个 得 分 ， 计 算 各 项 得 分 ， 最 终 选 出 得 分 值 
最 大 的 节点 作为 优选 的 结果 《也 是 调度 算法 的 结 末 ) 。 


下 面 是 对 所 有 优选 策略 的 详细 说 明 。 
1) LeastRequestedPriority 
该 优选 策略 用 于 从 备 选 节点 列表 中 选 出 资源 消耗 最 小 的 节点 。 


C1) 计算 出 所 有 备 选 节点 上 运行 的 Pod 和 备 选 Pod 的 CPU 占用 量 
totalMilliCPU。 


(2) 计算 出 所 有 备 选 节点 上 运行 的 Pod 和 备 选 Pod 的 内 存 占用 量 


total Memory。 





(3) 计算 每 个 节点 的 得 分 ， 计 算 规则 大 致 如 下 。 


NodeCpuCapacity 为 节点 CPU 计 算 能 力 ; NodeMemoryCapacity 为 节 
点 内 存 大 小 。 


score=int(((nodeCpuCapacity-totalMilliCPU)*10)/ nodeCpuCa 


2) CalculateNodeLabelPriority 


如 采用 户 在 配置 文件 中 指定 了 该 策略 ， 则 scheduler 会 通过 
RegisterCustomPriorityFunction 方 法 注册 该 策略 。 该 策略 用 于 判断 策略 列 
出 的 标签 在 备 选 节点 中 存在 时 ， 是 人 否 选择 该 备 选 节 点 。 如 果 备 选 节点 的 
标签 在 优选 策略 的 标签 列表 中 且 优 选 策 略 的 presence 值 为 tue， 或 者 备 选 
节点 的 标签 不 在 优选 策略 的 标签 列表 中 且 优 选 策略 的 presence 值 为 
false， 则 备 选 节点 Score=10， 和 否则 备 选 节点 Score=0。 





3) BalancedResourceAllocation 





该 优选 策略 用 于 从 备 选 节点 列表 中 选 出 各 项 资源 使 用 率 最 均衡 的 节 
Fao 


C1) 计算 出 所 有 备 选 节点 上 运行 的 Pod 和 备 选 Pod 的 CPU 占用 量 
totalMilliCPU。 


(2) 计算 出 所 有 备 选 节点 上 运行 的 Pod 和 备 选 Pod 的 内 存 占用 量 


totalMemory. 
(3) 计算 每 个 节点 的 得 分 ， 计 算 规 则 大 致 如 下 。 


NodeCpuCapacity 为 节点 CPU 计算 能 力 ;， NodeMemoryCapacity 为 节 
点 内 存 大 小 。 


score= int(10-math.Abs(totalMilliCPU/nodeCpuCapacity-tot 


3.4 ”kubelet 运 行 机 制 分 析 


在 Kubernetes 集 群 中 ， 在 每 个 Node 节 点 〈 又 称 Minion) 上 都 会 启动 
一 个 kubelet 服 务 进 程 。 访 进程 用 于 处 理 Master 节 点 下 发 到 本 节点 的 任 
务 ， 管 理 Pod 及 Pod 中 的 容器 。 每 个 kubeletj 进 程 会 在 API Server 上 注册 节 
点 目 身 信息 ， 定 期 加 Master 节 点 汇报 节点 资源 的 使 用 情况 ， 并 通过 
cAdvisor 监 控 容器 和 节点 资源 。 








节点 通过 设置 kubelet 的 启动 参数 “--register-node”， 来 决定 是 否 问 
API ”Server 注 册 自 己 。 如 果 该 参数 的 值 为 tue， 那 么 kubelet 将 试 着 通过 
API Server 注 册 自 己 。 在 自 注册 时 ，kubelet 启 动 时 还 包含 下 列 参 数 。 


。 --api-servers: 告诉 kubelet API Server 的 位 置 。 

。 --kubeconfig: 告诉 kubelet 在 哪儿 可 以 找到 用 于 访问 API Server 的 证 
Te 

e --cloud-provider: 告诉 kubelet 如 何 从 云 服 务 商 〈IaaSs) 那里 读 取 到 
和 自己 相关 的 元 数据 。 








当前 每 个 Kubelet 被 授予 创建 和 修改 任何 节点 的 权限 。 但 是 在 实践 
中 ， 它 仅仅 创建 和 修改 自己 。 将 来 ， 我 们 计划 限制 kubelet 的 权限 ， 仅 允 
许 它 修改 和 创建 其 所 在 节点 的 权限 。 如 果 在 集群 运行 过 程 中 遇 到 集群 次 
源 不 足 的 情况 ， 则 用 户 很 容易 通过 添加 机 器 及 运用 kubelet 的 自 注册 模式 
来 实现 扩容 。 








在 某 些 情况 下 ，Kubernetes 集 群 中 的 某 些 kubelet 没 有 选择 自 注册 模 
式 ， 用 户 需 要 自己 去 配置 Node 的 资源 信息 ， 同 时 告知 Node 上 的 kubelet 
API Server 的 位 置 。 集 群 管理 者 能 够 创建 和 修改 节点 信息 。 如 果 管 理 者 
希望 手动 创建 节点 信息 ， 则 通过 设置 kubelet 的 启动 参数 “--register- 
node=false” 即 可 。 











kubelet 在 启动 时 通过 API Server 注 册 节 点 信息 ， 并 定时 间 API Server 
发 送 节 点 的 新 消息 ，API Server 在 接收 到 这 些 信 息 后 ， 将 这 些 信 息 写 入 


etcd。 通 过 kubelet 的 启动 参数 “--node-status-update-frequency” 设 置 kubelet 
每 隔 多 少时 间 同 API Server 报 告 节 点 状态 ， 默 认为 10 秒 。 


3.4.2 Pod 管理 





kubelet 通 过 以 下 几 种 方式 获取 自 刁 Node 上 所 要 运行 的 Pod 清 单 。 


(1) XF: kubelet 启 动 参数 “--config” 指 定 的 配置 文件 目录 下 的 文 
件 ( 默 认 目 录 为 “/etc/kubemetes/manifests/”*”) 。 通 过 --file-check- 
frequency 设 置 检 查 该 文件 目录 的 时 间 间 隔 ， 默 认为 20 秒 。 


(2) HTTP 端 点 (URL) : 通过 “--manifest-url” 参 数 设 置 。 通 过 -- 
http-check-frequency 设 置 检查 该 HTTP 端 点 数据 的 时 间 间 隔 ， 默 认为 20 


秒 。 


(3) API Server: kubelet 通 过 API Server 监 听 etcd 目 录 ， 同 步 Pod 列 
FE 


所 有 以 非 API ”Server 方 式 创 建 的 Pod 都 叫 作 Static Pod. kubelet% 
Static Pod 的 状态 汇报 给 API Server，API Server 为 该 Static Pod 创 建 一 个 
Mirror Pod 和 其 相 匹 配 。Mirror Pod 的 状态 将 真实 反映 Static Pod 的 状态 。 
当 Static Pod 被 删除 时 ， 与 之 相对 应 的 Mirror Pod 也 会 被 删除 。 在 本 章 中 
我 们 只 讨论 通过 APIServer 获 得 Pod 清 单 的 方式 。kubelet 通 过 API Server 
Client 使 用 Watch 加 List 的 方式 监听 “registrynodes/$ 当 前 节点 的 名 
称 ” 和 “registry/pods” 目 录 ， 将 获取 的 信息 同步 到 本 地 缓存 中 。 





kubelet 监 听 etcd， 所 有 针对 Pod 的 操作 将 会 被 kubelet 监 听 到 。 如 果 发 
现 有 新 的 绑 定 到 本 节点 的 Pod， 则 按照 Pod 清 单 的 要 求 创建 该 Pod。 


如 果 发 现 本 地 的 Pod 被 修改 ， 则 kubelet 会 做 出 相应 的 修改 ， 比 如 删 
除 Pod 中 的 某 个 容器 时 ， 则 通过 Docker Client 删 除 该 容器 。 


如 果 发 现 删除 本 节点 的 Pod， 则 删除 相应 的 Pod， 并 通过 Docker 
Client 删 除 Pod 中 的 容器 。 


kubelet 读 取 监 听 到 的 信息 ， 如 果 是 创建 和 修改 Pod 任 务 ， 则 做 如 下 
处 理 。 


(1) 为 该 Pod 创 建 一 个 数据 目录 。 
(2) 从 API Server 读 取 该 Pod 清 单 。 
(3) 为 该 Pod 挂 载 外 部 卷 (External Volume) 。 


(4) 下 载 Pod 用 到 的 Secret。 





(5) 检查 已 经 运行 在 节点 中 的 Pod， 如 果 该 Pod 没 有 容器 或 Pause 容 
as (“kubernetes/pause” 镜 像 创 建 的 容器 〉 没 有 启动 ， 则 先 停止 Pod 里 所 
有 容器 的 进程 。 如 果 在 Pod 中 有 需要 删除 的 容器 ， 则 删除 这 些 容器 。 


(6) 用 “kubernetes/pause” 镜 像 为 每 个 Pod 创 建 一 个 容器 。 该 Pause 容 
器 用 于 接管 Pod 中 所 有 其 他 容器 的 网 络 。 每 创建 一 个 新 的 Pod，kubelet 都 
会 和 完 创 建 一 个 Pause 容 器 ， 然 后 创建 其 他 容器 。“kubernetes/pause” 镜 像 大 
概 为 200KB， 是 一 个 非常 小 的 容器 镜像 。 





(7) 为 Pod 中 的 每 个 容器 做 如 下 处 理 。 





。 为 容器 计算 一 个 hash 值 ， 然 后 用 容器 的 名 字 去 查询 对 应 Docker 容 器 
的 hash 值 。 知 碍 找到 容器 ， 且 两 者 的 hash 值 不 同 ， 则 停止 Docker 中 


容器 的 进程 ， 并 停止 与 之 关联 的 Pause 容 器 的 进程 ， 告 两 者 相同 ， 
则 不 做 任何 处 理 。 

。 如 果 容 器 被 终止 了 ， 且 容器 没有 指定 的 restartPolicy CEAR) ， 
则 不 做 任何 处 理 。 

。 调用 Docker Client 下 载 容 器 镜像 ， 调 用 Docker Client 运 行 容器 。 





3.4.3 ”容器 健康 检查 


Pod 通 过 两 类 探 针 来 检查 容器 的 健康 状态 。 一 个 是 LivenessProbe 探 
针 ， 用 于 判断 容器 是 否 健康 ， 告 诉 kubelet 一 个 容器 什么 时 候 处 于 不 健康 
的 状态 。 如 果 LivenessProbe 探 针 探 测 到 容器 不 健康 ， 则 kubelet 将 删除 该 
容器 ， 并 根据 容器 的 重启 策略 做 相应 的 处 理 。 如 果 一 个 容 髓 不 包含 
LivenessProbe 探 和 针 ， 那 么 kubelet 认 为 该 容器 的 LivenessProbe 探 针 返 回 的 
值 永 远 是 “Success”; 男 一 类 是 ReadinessProbe 探 针 ， 用 于 判断 容器 是 否 
启动 完成 ， 且 准备 接收 请 求 。 如 果 ReadinessProbe 探 针 检 测 到 失败 ， 则 
Pod 的 状态 将 被 修改 。Endpoint ”Controller 将 从 Service 的 Endpoint 中 删除 
包含 该 容器 所 在 Pod 的 IP 地 址 的 Endpoint 条 日 。 


kubelet 定 期 调用 容器 中 的 LivenessProbe 探 针 来 诊断 容器 的 健康 状 
况 。LivenessProbe 包 含 以 下 三 种 实现 方式 。 





(1) ExecAction: 在 容器 内 部 执行 一 个 命令 ， 如 果 该 命令 的 退出 
状态 码 为 0， 则 表明 容器 健康 。 





(2) TCPSocketAction: 通过 容器 的 IP 地 址 和 端口 号 执行 TCP 检 
查 ， 如 果 端 口 能 被 访问 ， 则 表明 容器 健康 。 


(3) HTTPGetAction: 通过 容器 的 耳 地 址 和 端口 号 及 路 径 调用 
HTTP Get 方 法 ， 如 果 响 应 的 状态 码 大 于 等 于 200 且 小 于 等 于 400， 则 认为 
容器 状态 健康 。 








LivenessProbe 探 针 包 含 在 Pod 定 义 的 spec.containers.{ 某 个 容器 } 中 。 


下 面 的 例子 展示 了 两 种 Pod 中 容 需 健康 检查 的 方式 :HITP 检 查 和 容器 命 
令 执行 检查 。 下 面 所 列 的 内 容 实现 了 通过 容 需 命令 执行 检查 : 





livenessProbe: 
exec: 
command: 
- cat 
- /tmp/health 
initialDelaySeconds: 15 


timeoutSeconds: 1 


kubelet 在 容器 中 执行 “cat/tmp/health”* 命 令 ， 如 果 该 命令 返回 的 值 为 
0， 则 表明 容器 处 于 健康 状态 ， 否 则 表明 容器 处 于 不 健康 状态 。 





下 面 所 列 的 内 容 实现 了 容器 的 HITP 检 得 : 


livenessProbe: 
httpGet: 
path: /healthz 
port: 8080 
initialDelaySeconds: 15 


timeoutSeconds: 1 


kubelet 发 送 一 个 HTTP 请 求 到 本 地 主机 和 端口 及 指定 的 路 径 ， 来 检 
查 容 需 的 健康 状况 。 


3.4.4 cAdvisor 资 源 监 控 


在 Kubernetes 集 群 中 如 何 监控 资源 的 使 用 情况 ? 


在 Kubernetes 集 群 中 ， 应 用 程序 的 执行 情况 可 以 在 不 同 的 级 别 上 监 
测 到 ， 这 些 级 别 包 括 : 容器 、Pod、Service 和 整个 集群 。 作 为 Kubernetes 
集群 的 一 部 分 ，Kubernetes 和 希望 提供 给 用 户 详细 的 各 个 级 别 的 资源 使 用 

言 轧 ， 这 将 使 用 户 能 够 深入 地 了 解 应 用 的 执行 情况 ， 并 找到 应 用 中 可 能 
的 瓶颈 。Heapster 项 目 为 Kubernetes 提 供 了 一 个 基本 的 监控 平台 ， 它 是 集 
群 级 别 的 监控 和 事件 数据 集成 器 〈Aggregator) 。Heapster 作 为 Pod 运 行 
在 Kubernetes 集 群 中 ， 和 运行 在 Kubernetes 集 群 中 的 其 他 应 用 相似 。 
Heapster Pod 通 过 kubelet (运行 在 节点 上 的 Kubernetes 代 理 ) 发 现 所 有 运 
行 在 集群 中 的 节点 ， 并 查看 来 自 这 些 节 点 的 资源 使 用 状况 信息 。kubelet 
通过 cAdvisor 获 取 其 所 在 节点 及 容器 的 数据 ，Heapster 通 过 和 带 着 关联 标 
签 的 Pod 分 组 这 些 信息 ， 这 些 数 据 被 推 到 一 个 可 配置 的 后 端 ， 用 于 存储 
和 可 视 化 展示 。 当 前 文 持 的 后 端 包 括 InfluxDB (with Grafana for 
Visualization) 和 Google Cloud Monitoring. 











cAdvisor 是 一 个 开源 的 分 析 容 器 资源 使 用 率 和 性 能 特性 的 代理 工 
有 具 。 它 是 因为 容 占 而 产生 的 ， 因 此 自然 文 持 Docker 容 器 。 在 Kubernetes 
项 目 中 ，cAdvisor 被 集成 到 Kubernetes 代 码 中 。cAdvisor 目 动 查 找 所 有 在 
其 所 在 节点 上 的 容器 ， 自 动 采 集 CPU、 内 存 、 文 件 系统 和 网 络 使 用 的 统 
计 信 息 。cAdvisor 通 过 它 所 在 节点 机 的 Root 容 器 ， 采 集 并 分 析 该 节点 机 
的 全 面 使 用 情况 。 





在 大 部 分 Kubernetes 集 群 中 ，cAdvisor 通 过 它 所 在 节点 机 的 4194 端 
口 暴 露 一 个 简单 的 UI。 图 3.8 是 cAdvisor 的 一 个 截图 。 
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13.8 ”cAdvisor 的 一 个 UI 


kubelet 作 为 连接 Kubernetes Master 和 各 节点 机 之 间 的 桥梁 ， 管 理 运 
行 在 节点 机 上 的 Pod 和 容器 。 人 已 的 成 员 容器 ， 同 
E RTO OE ER E 统计 信息 ， 然 后 通过 该 REST API 

这 些 聚 合 后 的 Pod 资 源 使 用 的 统计 信息 。 


3.5 ”kube-proxy 运 行 机 制 分 析 


我 们 在 前 面 已 经 了 解 到 ， 为 了 支持 集群 的 水 平 扩展 、 高 可 用 性 ， 
Kubernetes 抽 象 出 了 Service 的 概念 。Service 是 对 一 组 Pod 的 抽象 ， 它 会 根 
据 访 问 策略 〈 如 负载 均衡 策略 ) 来 访问 这 组 Pod。 


Kubernetes 在 创建 服务 时 会 为 服务 分 配 一 个 虚拟 的 耳 地 址 ， 客 户 端 
通过 访问 这 个 虚拟 的 耳 地 址 来 访问 服务 ， 而 服务 则 负责 将 请 求 转发 到 后 
端的 Pod 上 。 这 不 就 是 一 个 反 同 代理 吗 ? 不 错 ， 这 就 是 一 个 反 回 代理 。 
但 是 ， 它 和 普通 的 反 同 代理 有 一 些 不 同 : 首先 它 的 JP 地址 是 虚拟 的 ， 想 
从 外 面 访问 还 需要 一 些 技巧 ! 其 次 是 它 的 部 团 和 局 停 是 Kubernetes 统 一 
自动 管理 的 。 











Service 在 很 多 情况 下 只 是 一 个 概念 ， 而 真正 将 Service 的 作用 沙 实 的 
是 背后 的 kube-proxy 服 务 进 程 。 只 有 理解 了 kube-proxy 的 原理 和 机 制 ， 
我 们 才能 真正 理解 Service 背 后 的 实现 逻辑 。 


在 Kubernetes 集 群 的 每 个 Node 上 都 会 运行 一 个 kube-proxy 服 务 进 
程 ， 这 个 进程 可 以 看 作 Service 的 透明 代理 兼 负载 均衡 器 ， 其 核心 功能 是 
将 到 某 个 Service 的 访问 请 求 转发 到 后 端的 多 个 Pod 实 例 上 。 对 每 一 个 
TCP 类 型 的 Kubernetes ”Service，kube-proxy 都 会 在 本 地 Node 上 建立 一 个 
SocketServer 来 负责 接收 请 求 ， 然 后 均匀 发 送 到 后 端 某 个 Pod 的 端口 上 ， 
这 个 过 程 默 认 采 用 Round Robin 负 载 均衡 算法 。 另 外 ，Kubernetes 也 提供 
通过 修改 Service 的 Service.spec.sessionAffinity 参 数 的 值 来 实现 会 话 保持 
特性 的 定 同 转发 ， 如 果 设 置 的 值 为 “ClientIP”， 则 将 来 自 同一 个 ClientIP 


的 请 求 都 转发 到 同一 个 后 端 Pod 上 。 


此 外 ，Service 的 Cluster IP 与 NodePort 等 概念 是 kube-proxy 服 务 通 过 
Iptables 的 NAT 转 换 实现 的 ，kube-proxy 在 运行 过 程 中 动态 创建 与 Service 
相关 的 Iptables 规 则 ， 这 些 规则 实现 了 Cluster IP 及 NodePort 的 请 求 流量 重 
定 同 到 kube-proxy 进 程 上 对 应 服务 的 代理 端口 的 功能 。 由 于 Iptables 机 制 
针对 的 是 本 地 的 kube-proxy 端 口 ， 所 以 每 个 Node 上 都 要 运行 kube-proxy 
组 件 ， 这 样 一 来 ， 在 Kubernetes 集 群 内 部 ， 我 们 可 以 在 任意 Node 上 发 起 
对 Service 的 访问 请 求 。 


综 上 所 述 ， 由 于 kube-proxy 的 作用 ， 在 Service 的 调用 过 程 中 客户 端 
无 须 关 心 后 端 有 几 个 Pod， 中 间 过 程 的 通信 、 负 载 均 衡 及 故障 恢复 都 是 
透明 的 ， 如 图 3.9 所 示 。 


访问 Service 的 请 求 ， 不 论 是 用 Cluster IP+TargetPort 的 方式 ， 还 是 用 
节点 机 IP+NodePort 的 方式 ， 都 被 节点 机 的 Iptables 规 则 重 定向 到 kube- 
proxy 监 听 Service 服 务 代 理 端 口 。kube-proxy 接 收 到 Service 的 访问 请 求 
后 ， 会 如 何 选 择 后 端的 Pod 呢 ? 
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图 3.9 Service 的 负载 均衡 转发 规则 


自 先 ， 目 前 kube-proxy 的 负载 均衡 器 只 文 持 RoundRobin 算 法 。 
RoundRobin 算 法 按照 成 员 列 表 逐 个 选取 成 员 ， 如 果 一 轮 循 环 究 ， 便 从 头 
开始 下 一 轮 ， 如 此 循环 往复 。kube-proxy 的 负载 均衡 器 在 RoundRobin 算 
法 的 基础 上 还 支持 Session 保 持 。 如 果 Service 在 定义 中 指定 了 Session 保 
持 ， 则 kube-proxy 接 收 请 求 时 会 从 本 地 内 存 中 查找 是 否 存 在 来 自 该 请 求 
IP 的 affinityState 对 象 ， 如 果 存 在 该 对 象 ， 且 Session 没 有 超时 ， 则 kube- 
proxy 将 请 求 转向 该 affinityState 所 指 问 的 后 端 Pod。 如 果 本 地 存在 没有 来 
目 该 请 求 IP 的 affinityState 对 象 ， 则 按照 RoundRobin 算 法 为 该 请 求 挑选 一 
个 Endpoint， 并 创建 一 个 affinityState 对 象 ， 记 录 请 求 的 P 和 指 同 的 
Endpoint。 后 面 的 请 求 就 会 “ 笑 连 ”到 这 个 创建 好 的 affinityState 对 象 上 ， 
这 就 实现 了 客户 端 卫 会话 保持 的 功能 。 





接 下 来 我 们 深入 分 析 kube-proxy 的 实现 细节 。 


kube-proxy 通 过 查询 和 监听 API Server 中 Service 与 Endpoints 的 变化 ， 

为 每 个 Service 都 建立 了 一 个 “服务 代理 对 象 ”， 并 上 自动 同步 。 服 务 代理 对 
象 是 kube-proxy 程 序 内 部 的 一 种 数据 结构 ， 它 包括 一 个 用 于 监 昕 此 服务 
请 求 的 SocketServer，SocketServer 的 端口 是 随机 选择 的 一 个 本 地 空闲 端 
口 。 此 外 ，kube-proxy 内 部 也 创建 了 一 个 负载 均衡 器 
LoadBalancer，LoadBalancer 上 保存 了 Service 到 对 应 的 后 端 Endpoint 列 表 
的 动态 转发 路 由 表 ， 而 具体 的 路 由 选择 则 取决 于 Round Robin 负载 均衡 
算法 及 Service 的 Session 会 话 保持 (SessionAffinity〉 这 两 个 特性 。 








针对 发 生变 化 的 Service 列 表 ，kube-proxy 会 逐个 处 理 。 下 面 是 具体 
的 处 理 流程 。 


(1) 如 果 该 Service 没 有 设置 集群 IP (ClusterIP〉， 则 不 做 任何 处 
理 ， 人 否则 ， 获 取 该 Service 的 所 有 端口 定义 列表 (spec.ports 域 )。 








(2) 逐个 读 取 服 务 端口 定义 列表 中 的 端口 信息 ， 根 据 端口 名 称 、 
Service 名 称 和 Namespace 判 断 本 地 是 否 已 经 存在 对 应 的 服务 代理 对 象 ， 
如 果 不 存在 则 新 建 ; 如 果 存 在 并 且 Service 端 口 被 修改 过 ， 则 先 删 除 
Iptables 中 和 该 Service 端 口 相关 的 规则 ， 关 闭 服 务 代理 对 象 ， 然 后 走 新 建 
流程 ， 即 为 该 Service 瘦 口 分 配 服 务 代理 对 象 并 为 该 Service 创 建 相关 的 
Iptables 规 则 。 





(3) 更 新 负载 均衡 器 组 件 中 对 应 Service 的 转发 地 址 列表 ， 对 于 新 
建 的 Service， 确 定 转 发 时 的 会 话 保持 策略 。 


(4) 对 于 已 经 删除 的 Service 则 进行 清理 。 


而 针对 Endpoint 的 变化 ，kube-proxy 会 自动 更 新 负载 均衡 器 中 对 应 
Service 的 转发 地 址 列表 。 


下 面 讲 解 kube-proxy 针 对 Iptables 所 做 的 一 些 细节 操作 。 


kube-proxy 在 启动 时 和 监听 到 Service 或 Endpoint 的 变化 后 ， 会 在 本 
机 Iptables 的 NAT 表 中 添加 4 条 规则 链 。 


(1) KUBE-PORTALS-CONTAINER: MAE 中 通 it Service 
Cluster IP 和 端口 号 访问 Service 的 请 求 。 


(2) KUBE-PORTALS-HOST: 从 主机 中 通过 Service Cluster IP 和 
端口 号 访问 Service 的 请 求 。 


(3) KUBE-NODEPORT-CONTAINER: 从 容器 中 通过 Service 的 
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(4) KUBE-NODEPORT-HOST: 从 主机 中 通过 Service 的 NodePort 
端口 号 访问 Service 的 请 求 。 


此 外 ，kube-proxy 在 Iptables 中 为 每 个 Service 创 建 由 Cluster 
IP+Service 端 口 到 kube-proxy 所 在 主机 IP+Service 代 理 服 务 所 监听 的 端口 
的 转发 规则 。 转 发 规则 的 包 匹 配 规则 部 分 〈CRETIRIA) 如 下 所 示 : 


-m comment --comment $SERVICESTRING -p $PROTOCOL -m $PRO 





其 中 ,“-m comment--comment” 表 示 匹 配 规则 使 用 Iptables 的 显 式 扩 
展 的 注释 功能 ;“$SERVICESTRING” 为 注释 的 内 容 ; “-p$PROTOCOL- 
m$PROTOCOL--dport$DESTPORT-d$DESTIP” 表 示 协 议 
为 “$PROTOCOL” 且 目标 地 址 和 端口 为 “$DESTIP” 和 “$DESTPORT” 的 
包 ， 其 中 ，“$PROTOCOL” 可 以 为 TCP 或 
UDP, “$DESTIP” 和 “$DESTPORT” 为 Service 的 Cluster IP 和 TargetPort。 


对 于 转发 规则 的 跳 转 部 分 (-j 部 分 )， 如 果 请 求 来 日本 地 容器 ， 量 
Service 代 理 服务 监听 的 是 所 有 的 接口 (例如 IPv4 的 地 址 为 0.0.0.0〉 ， 则 
跳 转 部 分 如 下 所 示 : 





-] REDIRECT --to-ports $proxyPort 





其 表示 该 规则 的 功能 是 实现 数据 包 的 端口 重 定向 ， 重 定 癌 到 
$proxyPort 端 口 〈Service 代 理 服 务 监听 的 端口 ) ;人 否则 ， 跳 转 部 分 如 下 
所 示 : 


-j DNAT --to-destination proxyIP:proxyPort 


表示 该 规则 的 功能 是 实现 数据 包 转 发 ， 数 据 包 的 目的 地 址 变 
为 “proxyIP: proxyPort”( 即 Service 代 理 服务 所 在 的 卫 地 址 和 端口 ， 这 些 
地 址 和 端口 都 会 被 蕉 换 成 实际 的 地 址 和 端口 ) 。 


如 果 Service 类 型 为 NodePort， 则 kube-proxy 在 Iptables 中 除了 添加 上 
面 提 及 的 规则 ， 还 会 为 每 个 Service 创 建 由 NodePort 端 口 到 kube-proxy 所 
在 主机 IP+Service 代 理 服务 所 监听 的 端口 的 转发 规则 。 转 发 规则 的 包 匹 
配 规则 部 分 CCRETIRIA) 如 下 所 示 : 


-m comment --comment $SERVICESTRING -p $PROTOCOL -m $PRO- 


上 面 所 列 的 内 容 用 于 匹配 目的 问 口 为 <$NODEPORT” 的 包 。 
转发 规则 的 跳 转 部 分 (jj 部 分 〉》 和 前 面 提 及 的 跳 转 规则 一 致 。 


最 后 ， 我 们 以 本 书 第 2 章 的 Hello World 为 例 ， 看 看 kube-proxy 为 
redis-master 服 务 所 生成 的 Iptables 转 发 规则 : 


$ iptables-save | grep redis-master 
-A KUBE-PORTALS-CONTAINER -d 10.254.208.57/32 -p tcp -m ı 
-A KUBE-PORTALS-HOST -d 10.254.208.57/32 -p tcp -m comme! 


可 以 看 到 ， 对 “redis-master”Service 的 6379 端 口 的 访问 将 会 被 转发 到 
物理 机 的 42872 端 口上 。 而 42872 端 口 就 是 kube-proxy 为 这 个 Service 打 开 
的 随机 本 地 端口 。 


最 后 ， 给 出 本 市 的 一 个 总 结 性 的 示意 图 ， 如 图 3.10 所 示 。 
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为 每 个 Service Proxy 在 本 地 节点 打开 一 个 随机 选择 的 
端口 ，Proxy 决 定 哪个 后 台 Pod 被 选 定 。 任 何 访问 该 端 
口 的 连接 将 被 代理 到 相应 的 某 个 后 端 Pod。 
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图 3.10 ”kube-proxy 工 作 原 理 示 意图 


3.6 ”深入 分 析 和 集群 安全 机 制 


Kubernetes 通 过 一 系列 机 制 来 实现 集群 的 安全 控制 ， 其 中 包括 API 
Server 的 认证 授权 、 准 入 控制 机 制 及 保护 敏感 信息 的 Secret 机 制 等 。 集 群 
的 安全 性 必须 考虑 如 下 几 个 目标 。 


(1) 保证 容 需 与 其 所 在 的 簿 主机 的 隔离 。 





(2) 限制 容器 给 基础 设施 及 其 他 容器 带 来 消极 影响 的 能 


(3) 最 小 权限 原则 一 一 合理 限制 所 有 组 件 的 权限 ， 确 保 组 件 只 执 
行 它 被 授权 的 行为 ， 通 过 限制 单个 组 件 的 能 力 来 限制 它 所 能 到 达 的 权限 


(4) 明确 组 件 间 边 界 的 划分 。 
(5) 划分 普通 用 户 和 管理 员 的 角色 。 
(6) 在 必要 的 时 候 允 许 将 管理 员 权限 赋 给 普通 用 户 。 


(7) 允许 拥有 “Secret” 数 据 (Keys. Certs. Passwords) 的 应 用 在 
集群 中 运行 。 


下 面 分 别 从 Authentication、Authorization、Admission Control、 
Secret 和 Service Account 等 方面 来 说 明 集 群 的 安全 机 制 。 


3.6.1 API Server 认 证 


我 们 知道 ，Kubernetes 集 群 中 所 有 资源 的 访问 和 变更 都 是 通过 
Kubernetes API Server 的 REST API 来 实现 的 ， 所 以 集群 安全 的 关键 点 就 
在 于 如 何 识别 并 认证 客户 端 身 份 (Authentication) ， 以 及 随后 访问 权限 
的 授权 (Authorization) 这 两 个 关键 问题 ， 本 节 我 们 讲解 前 一 个 问题 。 


我 们 知道 ，Kubernetes 集 群 提 供 了 3 种 级 别 的 客户 端 身 份 认 证 方式 。 








。 最 严格 的 HTTPS 证 书 认证 : 基于 CA 根 证 书签 名 的 双向 数字 证 书 认 
证 7 fue 

e HTTP Token 认 证 : 通过 一 个 Token 来 识别 合法 用 户 。 

e HTTP Base 认 证 : 通过 用 户 名 + 密码 的 方式 认证 。 





首先 ， 我 们 说 说 HTTPS 证 书 认证 的 原理 。 


这 里 需要 有 一 个 CA 证 书 ， 我 们 知道 CA 是 PKI 系 统 中 通信 双方 都 信 
任 的 实体 ， 被 称 为 可 信 第 三 方 (Trusted Third Party, TTP) 。CA 作 为 可 
信 第 三 方 的 重要 条 件 之 一 就 是 CA 的 行为 具有 非 否 认 性 。 作 为 第 三 方 而 
不 是 简单 的 上 级 ， 就 必须 能 让 信任 者 有 追究 自己 责任 的 能 力 。CA 通 过 
证 书证 实 他 人 的 公 钥 信息 ， 证 书 上 有 CA 的 签名 。 用 户 如 果 因 为 信任 证 
书 而 有 了 损失 ， 则 证 书 可 以 作为 有 效 的 证 据 用 于 追究 CA 的 法 律 责任 。 
正 是 因为 CA 承担 责任 的 承诺 ， 所 以 CA 也 被 称 为 可 信 第 三 方 。 在 很 多 情 
况 下 ，CA 与 用 户 是 相互 独立 的 实体 ，CA 作 为 服务 提供 方 ， 有 可 能 因为 
服务 质量 问题 〈 例 如 ， 发 布 的 公 钥 数据 有 错误 ) 而 给 用 户 带 来 损失 。 在 
证 书 中 绑 定 了 公 钼 数据 和 相应 私 钥 拥有 者 的 身份 信息 ， 并 带 有 CA 的 数 




















字 签 名 ; 证 书 中 也 包含 了 CA 的 名 称 ， 以 便于 依赖 方 找 到 CA 的 公 钥 ， 验 
证 证 书 上 的 数字 签名 。 


CA 认证 涉及 诸多 概念 ， 比 如 根 证 书 、 自 签名 证 书 、 密 钥 、 私 钥 、 
加 密 算 法 及 HTTPS 等 ， 本 书 大 致 讲述 SSL 协 议 的 流程 ， 有 助 于 对 CA 认证 
和 Kubernetes CA 认证 的 配置 过 程 的 理解 。 


如 图 3.11 所 示 ，SSL 双 向 认证 大 概 包 含 下 面 几 个 步骤 。 


(1) HTTPS 通 信 双 方 的 服务 器 端 癌 CA 机 构 申 请 证 书 ，CA 机 构 是 
可 信 的 第 三 方 机 构 ， 它 可 以 是 一 个 公认 的 权威 的 企业 ， 也 可 以 是 企业 自 
喘 。 企 业内 部 系统 一 般 都 用 企业 自身 的 认证 系统 。CA 机 构 下 发 根 证 
书 、 服 务 端 证 书 及 私 钥 给 申请 者 。 











(2) HTTPS 通 信 双 方 的 客户 端 向 CA 机 构 申 请 证 书 ，CA 机 构 下 发 
根 证 书 、 客 户 端 证 书 及 私 钥 给 申请 者 。 
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发 送 的 相关 消 妃 是 人 否 一 致 ， 如 宁 一 致 ， 则 客户 端 认 可 这 个 服务 需 的 合法 
Att. 





(4) AP tin ROS PF rE 2S RA aie, ARS m BEC BEAU , 
通过 私 钥 解 密 证 书 ， 获 得 客户 病 证 书 公 钥 ， 并 用 该 公 钥 认证 证 书信 息 ， 
确认 客户 端 是 否 合 法 。 


(5) 客户 端 通过 随机 密 钥 加 密 信息 ， 并 发 送 加 密 后 的 信息 给 服务 
端 。 服 务 器 端 和 客户 端 协商 好 加 密 方案 后 ， 客 户 端 会 产生 一 个 随机 的 密 











钥 ， 和 客户 问 通过 协商 好 的 加 密 方 案 ， 加 密 该 随机 密 钥 ， 0 
钥 到 服务 器 端 。 服 务 费 端 接收 这 个 密 钥 后 ， 双 方 通信 的 所 有 内 容 都 通 


该 随机 密 钥 加 密 。 
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图 3.11 CA 认证 流程 


如 上 所 述 是 双向 认证 SSL 协 议 的 具体 通信 过 程 ， 这 种 情况 要 求 服 务 
器 和 用 户 双方 都 有 证 书 。 单 向 认证 SSL 协 议 不 需要 客户 拥有 CA 证 书 ， 对 
于 上 面 的 步 又， 只 需 将 服务 器 端 验证 客户 证 书 的 过 程 去 掉 ， 以 及 在 协商 
对 称 密码 方案 和 对 称 通话 密 钥 时 ， 服 务 器 发送 给 客户 的 是 没有 加 过 蜜 的 

《这 并 不 影响 SSL 过 程 的 安全 性 ) 密码 方案 。 








其 次 ， 我 们 来 看 看 HTTP Token 的 认证 原理 。 





HTTP Token 的 认证 是 用 一 个 很 长 的 特殊 编码 方式 的 并 且 难 以 被 模 
式 。 在 通常 情况 下 ， 
Token 是 一 个 很 复杂 的 字符 串 ， 比 如 我 们 用 私 钥 签 名 一 个 字符 串 后 的 数 
据 束 可 以 当 作 一 个 Token。 此 外 ， 每 个 Token 对 应 一 个 用 户 名 ， 存 储 在 
API Server 能 访问 的 一 个 文件 中 。 当 客户 端 发 起 API 调 用 请 求 时 ， 寅 要 在 
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HTTP Header 里 放 入 Token， 这 样 一 来 ，API Server 就 能 识别 合法 用 户 和 
非法 用 户 了 。 


最 后 ， 我 们 说 说 HTTP Base 认 证 。 


我 们 知道 ，HTTP 协 议 是 无 状态 的 ， 浏 览 器 和 Web 服 务 器 之 间 可 以 
通过 Cookie 来 进行 身份 识别 。 昌 面 应 用 程序 〈 比 如 新 浪 蝎 面 客户 端 、 
SkyDrive 客 户 端 、 命 令 行 程 序 ) 一 般 不 会 使 用 Cookie， 那 么 它们 与 Web 
服务 器 之 间 是 如 何 进行 身份 识别 的 呢 ? 这 就 用 到 了 HTTP Base 认 证 ， 这 
种 认证 方式 是 把 “用 户 名 + 冒号 + 密码 "用 BASE64 算 法 进行 编码 后 的 字符 
串 放 在 HTTP Request 中 的 Header Authorization 域 里 发 送 给 服务 端 ， 服 务 
端 收 到 后 进行 解码 ， 获 取 用 户 名 及 密码 ， 然 后 进行 用 户 身 份 的 鉴 权 过 


程 。 











3.6.2 API Server 授 权 


对 合法 用 户 进行 授权 (Authorization〉 并 且 随 后 在 用 户 访问 时 进行 
鉴 权 ， 是 权限 与 安全 系统 的 重要 一 环 。 简 单 地 说 ， 授 权 就 是 授予 不 同 的 
用 户 不 同 的 访问 权限 ，API Server 目 前 文 持 以 下 几 种 授权 策略 (通过 API 
Server 的 启动 参数 “--authorization_mode” 设 置 ) 。 





e AlwaysDeny. 
e AlwaysAllow. 
e ABAC., 


其 中 ，AlwaysDeny 表 示 拒 绝 所 有 的 请 求 ， 该 配置 一 般 用 于 测试 ; 
AlwaysAllow 表 示 接 收 所 有 的 请 求 ， 如 果 集 群 不 需要 授权 流程 ， 则 可 以 
采用 该 策略 ， 这 也 是 Kubernetes 的 默认 配置 ， ABAC (Attribute-Based 
Access Control) 为 基于 属性 的 访问 控制 ， 表 示 使 用 用 户 配置 的 授权 规则 
去 匹配 用 户 的 请 求 。 





为 了 简化 授权 的 复杂 度 ， 对 于 ABAC 模 式 的 授权 策略 ，Kubernetes 
仅 有 下 面 四 个 基本 属性 。 


。 用 户 名 代表 一 个 已 经 被 认证 的 用 户 的 字符 型 用 户 名 )〉。 
。 是 否 是 只 读 请 求 REST 的 GET 操 作 是 只 读 的 ) 。 
。 被 访问 的 是 哪 一 类 资源 ， 例 如 访问 Pod 资 
源 /api/v1/namespaces/default/pods。 
。 被 访问 对 象 所 属 的 Namespace。 


当 我 们 为 API ”Server 启 用 ABAC 模 式 时 ， 需 要 指定 授权 策略 文件 的 
KIEME (--authorization_policy_filesSOME_FILENAME) , ， 授 权 策 
略 文件 里 的 每 一 行 都 是 一 个 Map 类 型 的 JSON 对 象 ， 被 称 为 “访问 策略 对 
象 ”， 我 们 可 以 通过 设置 “访问 策略 对 象 ”" 中 的 如 下 属性 来 确定 具体 的 授 
权 行 为 。 





e user (HPZ): 为 字符 串 类 型 ， 该 字符 串 类 型 的 用 户 名 来 源 于 
Token 文 件 或 基本 认证 文件 中 的 用 户 名 字段 的 值 。 

e readonly〔 只 读 标 识 ) : 为 布尔 类 型 ， 当 它 的 值 为 true 时 ， 表 明 该 策 
略 允 许 GET 请 求 通过 。 

e resource CRW) : 为 字符 串 类 型 ， 来 自 于 URL 的 资源 ， 例 
如 “Pods”。 

e namespace 《命名 空 间 〉: 为 字符 串 类 型 ， 表 明 该 策略 允许 访问 某 
个 Namespace 的 资源 。 





例如 ， 我 们 要 实现 如 下 访问 控制 。 

a) 人 允许 用 户 alice 做 任何 事情 

(2) kubelet 只 能 访问 Pod 的 只 读 API。 

(3) kubelet 能 读 和 写 Event 对 象 。 

(4) 用 户 bob 只 能 访问 myNamespace 中 的 Pod 的 只 读 API。 
则 满足 上 述 要 求 的 授权 策略 文件 的 内 容 写 法 如 下 : 


{"user":"alice"} 


{"user":"kubelet", "resource": "pods", "readonly": true} 


"user":"kubelet", "resource": "events" 
F 


"user":"bob", "resource": "pods", "readonly": true, "ns 
T 
T 


当 客 户 端 发 起 API Server 调 用 时 ，API Server 内 部 要 先进 行 用 户 认 
证 ， 接 下 来 执行 用 户 鉴 权 流 程 ， 鉴 权 流 程 通 过 之 前 提 到 的 “授权 策略 ”来 
决定 一 个 API 调 用 是 否 合法 。 当 API Server 接 收 到 请 求 后 ， 会 读 取 该 请 求 
中 的 数据 ， 生 成 一 个 “访问 策略 对 象 ?， 如 果 该 请 求 中 不 融 某 些 属性 (如 
Namespace) ， 则 这 些 属性 的 值 将 根据 属性 类 型 的 不 同 ， 设 置 不 同 的 默 
认 值 (例如 为 字符 串 类 型 的 属性 设置 一 个 空 字 符 串 ;， 为 布尔 类 型 的 属性 
设置 false; 为 数值 类 型 的 属性 设置 0) 。 然 后 用 这 个 “访问 策略 对 象 ? 和 
授权 策略 文件 中 的 所 有 ?访问 策略 对 象 * 逐 条 匹配 ， 如 果 至 少 有 一 个 策略 
对 象 被 匹配 上 ， 则 该 请 求 将 被 鉴 权 通 过 ， 人 否则 终止 API 调 用 流程 ， 并 返 
回 客户 端 错误 调用 码 。 





3.6.3 Admission Control 准 入 控制 


突破 了 之 前 所 说 的 认证 和 鉴 权 两 道 关 口 之 后 ， 客 户 端 的 调用 请 求 束 
能 够 得 到 API Server 的 真正 响应 了 吗 ? 答案 是 : 不 能 ! 这 个 请 求 还 需要 
iit Admission Control 所 控制 的 一 个 “ 准 入 控制 链 ” 的 层 层 考验 ， 官 方 标 
准 的 “关卡 ”有 近 十 个 之 多 ， 而 且 能 自 定 义 扩 展 ! 笔者 忽然 在 想 ， 如 果 在 
幼儿 园 的 时 候 ， 老 师 就 告诉 我 们 长 大 后 还 要 读 小 学 ， 参 加 中 考 、 高 考 、 
公司 面试 、 职 称 考试 ， 等 等 ， 我 们 还 会 天 天 去 幼儿 园 吗 ? 


Admission Control 配 备 有 一 个 “ 准 入 控制 器 ”的 列表 ， 发 送 给 API 
Server 的 任何 请 求 都 需要 通过 列表 中 每 个 准 入 控制 器 的 检查 ， 检 查 不 通 
过 ， 则 API Server 拒 绝 此 调用 请 求 。 此 外 ， 准 入 控制 器 还 能 够 修改 请 求 
参数 以 完成 一 些 上 自动 化 的 任务 ， 比 如 ServiceAccount 这 个 控制 器 。 当 前 
可 配置 的 准 入 控制 器 如 下 。 





e AlwaysAdmit: 人 允许 所 有 请 求 。 
e AlwaysPulllmages: 在 司 动容 器 之 前 总 是 去 下 载 镜 像 ， 相 当 于 在 每 
个 容器 的 配置 项 imagePullPolicy=Always。 

e AlwaysDeny: 茶 止 所 有 请 求 ， 一 般 用 于 测试 。 

e DenyExecOnPrivileged: 它 会 拦截 所 有 想 在 Privileged Container EPA 
行 命令 的 请 求 。 如 果 你 的 集群 文 持 Privileged Container, KXK 
限制 用 户 在 这 些 Privileged ”Container 上 执行 命令 ， 那 么 强烈 推荐 你 
使 用 它 。 

e ServiceAccount: 这 个 plug-in 将 serviceAccounts 实 现 了 自动 化 ， 默 认 
启用 ， 如 果 你 想 要 使 用 ServiceAccount 对 象 ， 那 么 强烈 推荐 你 使 用 


它 ， 后 面 讲 述 ServiceAccount 的 章节 会 详细 说 明 其 作用 。 
SecurityContextDeny: 这 个 插件 将 使 用 了 SecurityContext 的 Pod 中 定 
义 的 选项 全 部 失效 。SecurityContext 在 Container 中 定义 了 操作 系统 
级 别 的 安全 设 定 (uid、gid、capabilities、SELinux 等 〉。 
ResourceQuota: 用 于 配额 管理 目的 ， 作 用 于 Namespace 上 ， 它 会 观 
察 所 有 的 请 求 ， 确 保 在 namespace 上 的 配额 不 会 超标 。 推 荐 在 
Admission Control 参 数列 表 中 这 个 插件 排 最 后 一 个 。 

LimitRanger: 用 于 配额 管理 ， 作 用 于 Pod 与 Container 上， 确保 Pod 与 

Container 上 的 配额 不 会 超标 。 

e NamespaceExists 〈 已 过 时 ) : 对 所 有 请 求 校 验 namespace 是 否 已 存 
在 ， 如 果 不 存 在 则 拒绝 请 求 。 已 合并 至 NamespaceLifecycle。 

e NamespaceAutoProvision (已 过 时 ) : 对 所 有 请 求 校 验 namespace， 
如 果 不 存 在 则 自动 创建 该 namespace， 推 荐 使 用 
NamespaceLifecycle. 

e NamespaceLifecycle: 如 果 尝 试 在 一 个 不 存在 的 namespace 中 创建 资 
源 对 象 ， 则 该 创建 请 求 将 被 拒绝 。 当 删除 一 个 namespace 时 ， 系 统 
将 会 删除 该 namespace 中 的 所 有 对 象 ， 包 括 Pod、Service 等 。 


在 API Server 上 设置 --admission-control 参 数 ， 即 可 定制 我 们 需要 的 
准 入 控制 链 ， 如 果 局 用 多 种 准 入 控制 选项 ， 则 建议 的 设置 〈 含 加 载 顺 
序 ) 如 下 : 


--admission-control=NamespaceLifecycle, LimitRanger, Secur: 


大 部 分 准 入 控制 器 都 比较 容易 理解 ， 我 们 接 下 来 着重 介绍 
SecurityContextDeny. ResourceQuotaLimitRangeriX =P HE A #2 iil] 48 o 


1) SecurityContextDeny 


SecurityContext 是 运用 于 容器 的 操作 系统 安全 设置 Cuid, gid, 
capabilities、SELinux role 等 ) 。Admission Control 的 
SecurityContextDeny 插 件 的 作用 是 ， 禁 止 创 建设 置 了 SecurityContext 的 
Pod， 例 如 包含 下 面 这 些 配置 项 的 Pod: 


spec.containers.securityContext.seLinuxOptions 


spec.containers.securityContext.runAsUser 


2) ResourceQuota 
{HEA F2 till 48 ResourceQuota{X He pR ill HE + Namespace # fi!) 22 A Ve 


的 数量 ， 而 且 能 够 限制 某 个 Namespace 中 被 Pod 所 请 求 的 资源 总 量 。 该 准 
入 控制 器 和 资源 对 象 ResourceQuota 一 起 实现 了 资源 配额 管理 。 


3) LimitRanger 


准 入 控制 器 LimitRanger 的 作用 类 似 于 上 面 的 ResourceQuota 控 制 
器 ， 针 对 Namespace 资 源 的 每 个 个 体 〈Pod 与 Container 等 ) 的 资源 配额 。 
该 插件 和 资源 对 象 LimitRange 一 起 实现 资源 限制 管理 。 


3.6.4 Service Account 





Service Account 也 是 一 种 账号 ， 但 它 并 不 是 给 Kubernetes 的 集群 的 用 
户 ( 系 统管 理 员 、 运 维 人 员 、 租 户 用 户 等 ) 使 用 的 ， 而 是 给 运行 在 Pod 
里 的 进程 用 的 ， 它 为 Pod 里 的 进程 提供 必要 的 喘 份 证 明 。 





在 继续 学 习 之 前 ， 请 回忆 一 下 本 章 前 面 所 说 的 API Server 的 认证 一 
Tp 


我 们 知道 ， 正 常情 况 下 ， 为 了 确保 Kubenetes 集 群 的 安全 ，API 
Server 都 会 对 客户 端 进行 身份 认证 ， 认 证 失败 的 客户 端 无 法 进行 API 调 
用 。 此 外 ，Pod 中 访问 Kubenetes API Server 服 务 的 时 候 ， 是 以 Service 方 
式 访问 服务 名 为 kubernetes 的 这 个 服务 的 ， 而 kubernetes 服 务 又 只 在 
HTTPS 安 全 端口 443 上 提供 服务 ， 那 么 如 何 进行 身份 认证 呢 ? 这 的 确 是 
个 谜 ， 因 为 Kubernetes 的 官方 文档 并 没有 清楚 说 明 这 个 问题 。 


通过 查看 官方 源码 ， 我 们 发 现 这 是 在 用 一 种 类 似 HTTP ”Token 的 新 
的 认证 方式 Service Account Auth，Pod 中 的 客户 端 调用 
kubernetesAPI 的 时 候 ， 在 HTTP Header 中 传递 了 一 个 Token 字 符 串 ， 这 类 
似 于 之 前 提 到 的 HTTP Token 认 证 方式 ， 但 又 有 以 下 几 个 不 同 点 。 








e 这 个 Token 的 内 容 来 自 Pod 里 指定 路 径 下 的 一 个 文件 
(/run/secrets/kubernetes.io/serviceaccount/token) ， 这 种 Token 是 动 
态 生 成 的 ， 确 切 地 说 ， 是 由 Kubernetes Controller 进 程 用 API Server 
的 私 钥 〈--service-account-private-key-file 指 定 的 私 钥 ) 签名 生成 的 
一 个 JWT Secret. 








。 官方 提供 的 客户 端 REST 框 架 代 码 里 ， 通 过 HTTPS 方 式 与 API Server 

建立 连接 后 ， 会 用 Pod 里 指定 路 径 下 的 一 个 CA 证 书 
(/run/secrets/kubernetes.io/serviceaccount/ca.crt) 验证 API Server 发 
来 的 证 书 ， 验 证 是 否 是 被 CA 证 书签 名 的 合法 证 书 。 

e API Server 收 到 这 个 Token 以 后 ， 采 用 目 己 的 私 铀 《实际 是 使 用 参数 
SerVice-account-key-file 指 定 的 私 铀 ， 如 果 此 参数 没有 设置 ， 则 默认 
采用 ts-private-key-file 指 定 的 参数 ， 即 目 己 的 私 钥 ) 对 Token 进 行 合 
法 性 验证 。 


明白 了 认证 原理 ， 我 们 接 下 来 继续 分 析 上 面 认 证 过 程 中 所 涉及 的 
Pod 中 的 以 下 三 个 文件 。 


e /run/secrets/kubernetes.io/serviceaccount/token. 

e /run/secrets/kubernetes.io/serviceaccount/ca.crt. 

e /run/secrets/kubernetes.io/serviceaccount/namespace 〈 客 户 端 采用 这 里 
指定 的 namespace 作 为 参数 调用 Kubernetes API) 。 


三 个 文件 由 于 参与 到 Pod 进 程 与 API Server 认 证 的 过 程 中 ， 起 到 了 
类 1 a 《私密 和 凭据》 的 作用 ， 所 以 它们 被 称 为 Kubernetes Secret 对 
象 。Secret 从 属于 Service Account 资 源 对 象 ， 属 于 Service Account 的 一 部 
分 ， 一 个 Service Account 对 象 里 面 可 以 包括 多 个 不 同 的 Secret 对 象 ， 分 别 
用 于 不 同 目的 的 认证 活动 。 


下 面 我 们 通过 运行 一 些 命令 来 加 深 我 们 对 Service Account 与 Secret 的 
直观 认识 。 


首先 ， 查 看 系统 中 的 Service Account 对 象 ， 我 们 看 到 有 一 个 名 为 
default 的 Service Account 对 象 ， 包 售 一 个 名 为 default-token-77oyg 的 


Secret， 这 个 Secret 同 时 是 “Mountable secrets”， 表 明 它 是 需要 被 Mount 到 
Pod 上 的 : 


# kubectl describe serviceaccounts 
Name: default 


Namespace: default 


Labels: <none> 

Image pull secrets: <none> 

Mountable secrets: default -token-77oyg 
Tokens: default -token-77oyg 


接 下 来 ， 我 们 看 看 default-token-77oyg 都 有 什么 内 容 : 


# kubectl describe secrets default-token-77oyg 

Name: default-token-77oyg 

Namespace: default 

Labels: <none> 

Annotations: kubernetes.10/service-account .name=de’ 


kubernetes.io0/service-account.uid=3e5b99c0- 43: 


Type: kubernetes.i0/service-account-token 

Data 

token: ey JhbGci0iJSUZI1NiIsInR5cCI6IkpxvCcJ9g.« 
ca.crt: 1115 bytes 


namespace: 7 bytes 


从 上 面 的 输出 信息 中 我 们 看 到 ，default-token-77oyg 包 括 三 个 数据 
项 ， 分 别 是 token、ca.crt、namespace。 联 想到 “Mountable ”secrets” 的 标 
记 ， 以 及 之 前 看 到 的 Pod 中 的 三 个 文件 的 文件 名 ， 你 可 能 悦 然 大 悟 ， 原 
来 是 这 么 一 回 事 : 每 个 Namespace 下 有 一 个 名 为 default 的 默认 的 
SerivceAccount 对 象 ， 这 个 SerivceAccount 里 面 有 一 个 名 为 Tokens 的 可 以 
当 作 Volume 一 样 被 Mount 到 Pod 里 的 Secret， 当 Pod 启 动 时 ， 这 个 Secret 会 
自动 被 Mount 到 Pod 的 指定 目录 下 ， 用 来 协助 完成 Pod 中 的 进程 访问 API 
Server 时 的 吴 份 鉴 权 过 程 。 


如 图 3.12 所 示 ， 一 个 Service Account 可 以 包括 多 个 Secret 对 象 。 


在 service account 中 Secret 
用 于 访问 API Server 
的 Secret 


Secret 


在 service account} 
用 于 下 载 image 的 
Secret 





图 3.12 Service Account 中 的 Secret 


(1) 名 为 Tokens 的 Secret 用 于 访问 API ， Server 的 Secret， 也 被 称 为 


Service Account Secret. 


(2) 名 为 Image pull secrets 的 Secret 用 于 下 载 容 器 镜像 时 的 认证 过 
程 ， 通 党 镜像 库 运 行 在 Insecure 模 式 下 ， 所 以 这 个 Secret 为 空 。 


(3) 用 户 自 定 义 的 其 他 Secret， 用 于 用 户 的 进程 。 





如 果 一 个 Pod 在 定义 时 没有 指定 spec.serviceAccountName 属 性 ， 则 系 
统 会 自动 为 其 赋值 为 “default”， 即 大 家 都 使 用 同一 个 Namespace 下 默认 
的 Service Account。 如 果 某 个 Pod 需 要 使 用 非 default 的 Service Account, 
则 需要 在 定义 时 指定 : 








apiVersion: v1 
kind: Pod 
metadata: 

name: mypod 
spec: 

containers: 

- name: mycontainter 
image: nginx:v1 


serviceAccountName: myserviceaccount 


Kubernetes 之 所 以 要 创建 两 套 独立 的 账号 系统 ， 原 因 如 下 。 


e User 账 号 是 给 人 用 的 ，Service Account 是 给 Pod 里 的 进程 使 用 的 ， 面 
回 的 对 象 不 同 。 

。 User 账 扎 是 全 局 性 的 ，Service Account 则 属于 某 个 有 具体 的 
Namespace。 

。 通常 来 说 ，User 账 号 是 与 后 端的 用 户 数据 库 同 步 的 ， 创 建 一 个 新 用 
户 通 党 要 走 一 套 复杂 的 业务 流程 才能 实现 ，Service _ Account 的 创建 
则 需要 极 轻 量 级 的 实现 方式 ， 集 群 管理 员 可 以 很 容易 为 某 些 特定 任 
务 创建 一 个 Service Account. 

。 对 于 这 两 种 不 同 的 账号 ， 其 审计 要 求 通常 不 同 。 





。 对 于 一 个 复杂 的 系统 来 说 ， 多 个 组 件 通常 拥有 各 种 账号 的 配置 信 
i, Service Account 是 Namespace 陋 离 的 ， 可 以 针对 组 件 进 行 一 对 
一 的 定义 ， 同 时 有 具备 很 好 的 “便携 性 ”。 





接 下 来 ， 我 们 深入 分 析 Service ”Account 与 Secret 相 关 的 一 些 运行 机 
制 | 。 


前 面 的 Controller Manager 原 理 分 析 一 节 中 ， 我 们 知道 Controller 
manager 创 建 了 ServiceAccount Controller 与 Token Controller 两 个 安全 相关 
的 控制 器 。 其 中 ServiceAccount Controller 一 直 监 昕 Service Account#ll 
Namespace 的 事件 ， 如 果 一 个 Namespace 中 没有 default Service Account， 
那么 ServiceAccount Controller 就 会 为 该 Namespace 创 建 一 个 默认 

(default) 的 Service Account， 这 就 是 我 们 之 前 看 到 每 个 Namespace 下 都 
有 一 个 名 为 default 的 Service Account 的 原因 了 。 


如 果 Controller manager 进 程 在 启动 时 指定 了 API Server# 4H 
(service-account-private-key-file#2%) ， 那 么 Controller manager 会 创建 
Token Controller. Token Controller 也 监听 Service Account 的 事件 ， 如 果 
发 现 新 创建 的 Service Account 里 没有 对 应 的 Service Account Secret， 则 会 
用 API Server 私 钥 创建 一 个 Token (JWT Token) ， 并 用 该 Token、CA 证 
书 及 Namespace 名 称 等 三 个 信息 产生 一 个 新 的 Secret 对 象 ， 然 后 放 入 刚才 
的 Service Account'#; 如果 监听 到 的 事件 是 删除 Service _ Account 事件 ， 
则 自动 删除 与 该 Service Account 相 关 的 所 有 Secret。 此 外 ，Token 
Controller 对 象 同 时 监听 Secret 的 创建 、 修 改 和 删除 事件 ， 并 根据 事件 的 
不 同 做 不 同 的 处 理 。 


当 我 们 在 API Server 的 鉴 权 过 程 中 启用 了 Service Account 类 型 的 准 入 
控制 器 ， 即 在 kube-apiserver 启 动 参数 中 包括 下 面 的 内 容 时 : 


--admission_control=ServiceAccount 


则 针对 Pod 新 增 或 修改 的 请 求 ，Service ”Account 准 入 控制 器 会 验证 


Pod 里 的 Service Account 是 否 合 法 。 


(1) 如 果 spec.serviceAccount 域 没有 被 设置 ， 则 Kubernetes 默 认为 
其 指定 名 字 为 default 的 Service accout. 


(2) 如果 Pod 的 Spec.serviceAccount 域 指定 了 default 以 外 的 Service 
Account， 而 该 Service Account 没 有 事先 被 创建 ， 则 该 Pod 操 作 失 败 。 


(3) 如果 在 Pod 中 没有 指定 “ImagePullSecrets”， 那 么 这 个 
spec.serviceAccount 域 指定 的 Service _ Account 的 “ImagePullSecrets” 会 被 加 
入 该 Pod 中 。 


(4) 给 Pod 添 加 一 个 特殊 的 Volume， 在 该 Volume 中 包含 Service 
Account ” Secret 中 的 Token， 并 将 Volume 挂 载 到 Pod 中 所 有 容器 的 指定 日 


录 下 (/var/run/secrets/kubernetes.io/serviceaccount) 。 





综 上 所 述 ，Service Account 的 正常 工作 离 不 开 以 下 几 个 控制 器 。 
(1) Admission Controller。 
(2) Token Controller。 


(3) ServiceAccount Controller。 


3.6.5 Secret Z EJE 


上 一 节 我 们 提 到 Secret 对 象 ，Secret 的 主要 作用 是 保管 私密 数据 ， 比 
如 密码 、OAuth Tokens、SSH Keys 等 信息 。 将 这 些 私 密 信 息 放 在 Secret 
对 象 中 比 直 接 放 在 Pod 或 Docker Image 中 更 安全 ， 也 更 便于 使 用 和 分 
Ke 








下 面 的 例子 用 于 创建 一 个 Secret: 


Secrets .yaml: 
apiVersion: vi 
kind: Secret 
metadata: 
name: mysecret 
type: Opaque 
data: 
password: dmFsdwUtMgOK 


username: dmFsdwUtMQOK 


# kubectl create -f secrets.yaml 


在 上 面 的 例子 中 ，data 域 的 各 子 域 的 值 必 须 为 BASE64 编 码 值 ， 其 
中 password 域 和 username 域 BASE64 编 码 前 的 值 分 别 为 “value-1” 和 “value- 
26 


一 旦 Secret 被 创建 ， 则 可 以 通过 下 面 的 三 种 方式 使 用 它 。 


(1) 在 创建 Pod 时 ， 通 过 为 Pod 指 定 Service Account 来 自动 使 用 该 


Secret. 

(2) 通过 挂 载 该 Secret 到 Pod 来 使 用 它 。 

(3) Docker 镜 像 下 载 时 使 用 ， 通 过 指定 Pod 的 spc.ImagePullSecrets 
来 引用 它 。 


第 1 种 使 用 方式 主要 用 在 API Server 鉴 权 方面 ， 之 前 我 们 提 到 过 。 下 
面 的 例子 展示 了 第 2 种 使 用 方式 : 将 一 个 Secret 通 过 挂 载 的 方式 添加 到 
Pod 的 Volume 中 。 





apiVersion: v1 
kind: Pod 
metadata: 

name: mypod 

namespace: myns 

spec: 

containers: 

- name: mycontainer 
image: redis 
volumeMounts: 

- name: foo 
mountPath: "/etc/foo" 
readOnly: true 


volumes: 


- name: foo 
secret: 


secretName: mysecret 


其 结果 如 图 3.13 所 示 。 





图 3.13” 挂 载 Secret 到 Pod 


第 3 种 使 用 方式 的 使 用 流程 如 下 。 
(1) 执行 login 命 令 ， 登 录 私 有 Registry: 


# docker login localhost:5000 


输入 用 户 名 和 密码 ， 如 果 是 第 1 次 登录 系统 ， 则 会 创建 新 用 户 ， 相 
关 信 息 会 写 入 ~/.dockercfg 文 件 中 。 


(2) 用 BASE64 编 码 dockercfg 的 内 容 : 


# cat ~/.dockercfg | base64 


(3) 将 上 一 步 命令 的 输出 结果 作为 Secret 的 “data.dockercfg” 域 的 内 
由 此 来 创建 一 个 Secret: 


image-pull-secret.yaml: 
apivVersion: v1 
kind: Secret 
metadata: 
name: myregistrykey 
data: 
.dockercfg: eyALaHROCHM6Ly9pbmRleC5kb2NrZXIuaw8vdjEvij 


type: kubernetes.io/dockercfg 


# kubectl create -f image-pull-secret.yaml 


(4) 在 创建 Pod 时 引用 该 Secret: 


pods .yamJ]: 
apiVersion: v1 
kind: Pod 
metadata: 

name: mypod2 
spec: 

containers: 

- name: foo 


image: janedoe/awesomeapp: v1 


imagePullSecrets: 


- name: myregistrykey 


$ kubectl create -f pods.yaml 


其 结果 如 图 3.14 所 示 。 


myregistrykey 





图 3.14 imagePullSecret 引 用 Secret 


每 个 单独 的 Secret 大 小 不 能 超过 1MB，Kubernetes 不 鼓励 创建 大 尺寸 
的 Secret， 因 为 如 果 使 用 大 尺寸 的 Secret， 则 将 大 量 占用 API ”Server 和 和 
kubelet 的 内 存 。 当 然 ， 创 建 许多 小 的 Secret 也 能 耗 尽 API Server 和 kubelet 
的 内 存 。 


在 使 用 Mount 方 式 挂 载 Secret 时 ，Container 中 Secret 的 “data” 域 的 各 个 
域 的 Key 值 作为 目录 中 的 文件 ，Value 值 被 BASE64 编 码 后 存储 在 相应 的 
文件 中 。 前 面 的 例子 中 创建 的 Secret， 被 挂 载 到 一 个 叫 作 mycontainer 的 
Container 中 ， 在 该 Container 中 可 通过 相应 的 查询 命令 查看 所 生成 的 文件 
和 文件 中 的 内 容 ， 如 下 所 示 : 


$ ls /etc/foo/ 

username 

password 

$ cat /etc/foo/username 
value-1 

$ cat /etc/foo/password 


value-2 


通过 上 面 的 例子 可 以 得 出 如 下 结论 : 我 们 可 以 通过 Secret 保 管 其 他 
系统 的 敏感 信息 《比如 数据 库 的 用 户 名 和 密码 ) ， 并 以 Mount 的 方式 将 
Secret 挂 载 到 Container 中 ， 然 后 通过 访问 目录 中 的 文件 的 方式 获取 该 敏 
感 信息 。 当 Pod 被 API Server 创 建 时 ，API Server 不 会 校 验 该 Pod 引 用 的 
Secret 是 否 存 在 。 一 旦 这 个 Pod 被 调度 ， 则 kubelet 将 试 着 获取 Secret 的 
值 。 如 果 Secret 不 存在 或 暂时 无 法 连接 到 API Server， 则 kubelet 将 按 一 定 
的 时 间 间 隔 定 期 重 试 获取 该 Secret， 并 发 送 一 个 Event 来 解释 Pod 没 有 启 
动 的 原因 。 一 旦 Secret 被 Pod 获 取 ， 则 kubelet 将 创建 并 Mount 包 含 Secret 的 
Volume。 只 有 所 有 Volume 被 Mount 后 ，Pod 中 的 Container 才 会 被 启动 。 
在 kubelet 启 动 Pod 中 的 Container 后 ，Container 中 的 和 Secret 相 关 的 Volume 
将 不 会 被 改变 ， 即 使 Secret 本 里 被 修改 了 。 为 了 使 用 更 新 后 的 Secret， 必 
须 删除 旧 的 Pod， 并 重新 创建 一 个 新 的 Pod， 因 此 更 新 Secret 的 流程 和 部 
署 一 个 新 的 Image 是 一 样 的 。 


3.7 网络 原理 


关于 Kubernetes 网 络 ， 我 们 通常 有 这 些 问题 需要 回答 ， 如 图 3.15 所 


Kubernetes 的 网 络 模型 是 什么 | 
Docker 背后 的 网 络 基 础 是 什么 | 
Docker 日 身 的 网 络 模型 和 局 限 
Kubernetes 的 网 络 组 件 之 间 是 怎么 通信 的 





外 部 如 何 访问 Kubernetes 的 集群 
有 哪些 开源 的 组 件 支持 Kubernetes 的 网 络 模型 





13.15 ”Kubermnetes 的 常见 问题 


在 本 节 我 们 分 别 回答 这 些 问题 ， 然 后 通过 一 个 具体 的 实验 来 将 这 些 
相关 的 知识 串联 成 一 个 整体 。 


3.7.1 Kubernetes 网 络 模 型 





Kubernetes 网 络 模型 设计 的 一 个 基础 原则 是 : 每 个 Pod 都 拥有 一 个 独 
立 的 IP 地 址 ， 而 且 假 定 所 有 Pod 都 在 一 个 可 以 直接 连通 的 、 局 平 的 网 络 
空间 中 。 所 以 不 管 它 们 是 否 运 行 在 同一 个 Node( 箱 主机 〉 中 ， 都 要 求 它 
们 可 以 直接 通过 对 方 的 人 P 进 行 访问 。 设 计 这 个 原则 的 原因 是 ， 用 户 不 需 
要 额外 考虑 如 何 建 并 Pod 之 间 的 连接 ， 也 不 需要 考虑 将 容器 端口 映射 到 
主机 端口 等 问题 。 








实际 上 在 Kubernetes 的 世界 里 ，IP 是 以 Pod 为 单位 进行 分 配 的 。 一 个 
Pod 内 部 的 所 有 容器 共享 一 个 网 络 堆栈 (实际 上 就 是 一 个 网 络 命名 空 
间 ， 包 括 它 们 的 耳 地 址 、 网 络 设备 、 配 置 等 都 是 共享 的 ) 。 按 照 这 个 网 
络 原则 抽象 出 来 的 一 个 Pod 一 个 IP 的 设计 模型 也 被 称 作 IP-per-Pod 模 型 。 





由 于 Kubernetes 的 网 络 模型 假设 Pod 之 则 访问 时 使 用 的 是 对 方 Pod 的 
实际 地 址 ， 所 以 一 个 Pod 内 部 的 应 用 程序 看 到 的 自己 的 JP 地 址 和 端口 与 
集群 内 其 他 Pod 看 到 的 一 样 。 它 们 都 是 Pod 实 际 分 配 的 IP 地 址 (从 
docker0 上 分 配 的 ) 。 将 耻 地 址 和 端口 在 Pod 内 部 和 外 部 都 保持 一 致 ， 我 
们 可 以 不 使 用 NAT 来 进行 转换 ， 地 址 空间 也 自然 是 平 的 。Kubernetes 的 
网 络 之 所 以 这 么 设计 ， 主 要 原因 就 是 可 以 兼容 过 去 的 应 用 。 当 然 ， 我 们 
使 用 Linux 命 令 “ip addr show” 也 能 看 到 这 些 地 址 ， 和 程序 看 到 的 没有 什 
么 区 别 。 所 以 这 种 IP-per-Pod 的 方案 很 好 地 利用 了 现 有 的 各 种 域名 解析 
和 发 现 机 制 。 





一 个 Pod 一 个 IP 的 模型 还 有 为 外 一 层 含 义 ， 那 束 古 同一 个 Pod 内 的 不 





同 容 器 将 会 共享 一 个 网 络 命名 空间 ， 也 就 是 说 同一 个 Linux 网 络 协议 
栈 。 这 束 意 味 着 同一 个 Pod 内 的 容器 可 以 通过 localhost 来 连接 对 方 的 端 
口 。 这 种 关系 和 同一 个 VM 内 的 进程 之 间 的 关系 是 一 样 的 ， 看 起 来 Pod 内 
的 容 右 之 间 的 隔离 性 降低 了 ， 而 且 Pod 内 不 同 容器 之 间 的 端口 是 共享 
的 ， 没 有 所 谓 的 私有 端口 的 概念 了 。 如 果 你 的 应 用 必须 要 使 用 一 些 特定 
的 端口 范围 ， 那 么 你 也 可 以 为 这 些 应 用 单独 创建 一 些 Pod。 反 之 ， 对 那 
些 没有 特殊 需要 的 应 用 ， 这 样 做 的 好 处 是 Pod 内 的 容器 是 共享 部 分 资源 
的 ， 通 过 共享 资源 互相 通信 显然 更 加 容易 和 高 效 。 针 对 这 些 应 用 ， 虽 然 
损失 了 可 接受 范围 内 的 部 分 隔离 性 ， 但 也 是 值得 的 。 





IP-per-Pod 模 式 和 Docker 原 生 的 通过 动态 端口 映射 方式 实现 的 多 节 
点 访问 模式 有 什么 区 别 呢 ? 主要 区 别 是 后 者 的 动态 端口 映射 会 引入 端口 
管理 的 复杂 性 ， 而 且 访问 者 看 到 的 了 P 地 址 和 端口 与 服务 提供 者 实际 绑 定 
的 不 同 《 因 为 NAT 的 缘故 ， 它 们 都 被 映射 成 新 的 地 址 或 端口 了 ) ， 这 也 
会 引起 应 用 配置 的 复杂 化 。 同 时 ， 标 准 的 DNS 等 名 字 解 析 服 务 也 不 适用 
了 。 甚 至 服务 注册 和 发 现 机 制 都 将 受到 挑战 ， 因 为 在 端口 映射 情况 下 ， 
服务 自 遇 很 难 知道 自己 对 外 其 圳 的 真实 的 服务 IP 和 病 口 。 而 外 部 应 用 也 
无 法 通过 服务 所 在 容器 的 私有 卫 地 址 和 端口 来 访问 服务 。 








总 的 来 说 ，IP-per-Pod 模 型 是 一 个 简单 的 兼容 性 较 好 的 模型 。 从 该 
模型 的 网 络 的 端口 分 配 、 域 名 解析 、 服 务 友 现 、 负 和 载 均衡 、 应 用 配置 和 
迁移 等 角度 来 看 ，Pod 都 能 够 被 看 作 一 台独 立 的 “虚拟 机 ?或 “物理 机 ?”。 


按照 这 个 网 络 抽象 原则 ，Kubernetes 对 网 络 有 什么 前 提 和 要 求 呢 ? 
Kubernetes 对 集群 的 网 络 有 如 下 要 求 : 


(1) 所 有 容器 都 可 以 在 不 用 NAT 的 方式 下 同 别 的 容器 通信 ; 


(2) 所 有 节点 都 可 以 在 不 用 NAT 的 方式 下 同 所 有 容器 通信 ， 反 之 
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(3) 容 露 的 地 址 和 别人 看 到 的 地 址 是 同一 个 地 址 。 





这 些 基 本 的 要 求 意 味 着 并 不 是 只 要 两 台 机 器 运行 Docker， 
Kubernetes 就 可 以 工作 了 。 具 体 的 集群 网 络 实现 必 须 保障 上 述 基 本 要 
求 ， 原 生 的 Docker 网 络 目 前 还 不 能 很 好 地 支持 这 些 要 求 。 





实际 上 ， 这 些 对 网 络 模型 的 要 求 并 没有 降低 整个 网 络 系统 的 复杂 
度 。 如 果 你 的 程序 原来 在 VM 上 运行 ， 而 那些 VM 拥有 独 六 IP， 并 且 它 们 
之 间 可 以 直接 透明 地 通信 ， 那 么 Kubernetes 的 网 络 模 型 就 和 VM 使 用 的 网 
络 模型 是 一 样 的 。 所 以 使 用 这 种 模型 可 以 很 容易 地 将 已 有 的 应 用 程序 从 
VM 或 者 物理 机 迁移 到 容器 上 。 








当然 ， 谷 歌 设计 Kubernetes 的 一 个 主要 运行 基础 就 是 其 云 环 境 
GCE (Google Compute Engine) ， 在 GCE 下 这 些 网 络 要求 都 是 默认 文 持 
的 。 另 外 ， 第 见 的 其 他 公有 云 服 务 商 如 亚马逊 等 ， 在 它们 的 公有 云 计 算 
环境 下 也 是 默认 文 持 这 个 模型 的 。 








由 于 部 蜀 私 有 云 的 场景 会 ， 所 以 在 私有 云 中 运行 
Kubernetes+Docker 集 群 之 前 ， 就 上 自己 搭建 出 符合 Kubernetes 要 求 的 
网 络 环境 。 现 在 的 开源 世界 有 很 多 开源 组 件 可 以 帮助 我 们 打通 Docker 容 
器 和 容器 之 间 的 网 络 ， 实 现 Kubernetes 要 求 的 网 络 模型 。 当 然 每 种 方案 
都 有 适合 的 场景 ， 我 们 要 根据 自己 的 实际 需要 进行 选择 。 在 后 面 的 章 市 
中 会 对 常见 的 开源 方案 进行 介绍 








Kubernetes 的 网 络 依赖 于 Docker，Docker 的 网 络 又 离 不 开 Linux 操 作 
系统 内 核 特 性 的 支持 ， 所 以 我 们 有 必要 先 深入 了 解 Docker 背 后 的 网 络 原 


理 和 基础 知识 。 接 下 来 我 们 一 起 深入 学 习 一 些 必 要 的 Linux 网 络 知识 。 


3.7.2 ”Docker 的 网 络 基础 


Docker 本 身 的 技术 依赖 于 近年 Linux 内 核 虚拟 化 技术 的 发 展 ， 所 以 
Docker 对 Linux 内 核 的 特性 有 很 强 的 依赖 。 这 里 将 Docker 使 用 到 的 与 
Linux 网 络 有 关 的 主要 技术 进行 简要 介绍 ， 这 些 技术 包括 如 下 几 种 ， 如 
图 3.16 所 示 。 


Network Namespace《〈 网 络 命名 空间 ) 
Veth 设备 对 | 
Iptables/Netfilter | 
网 桥 | 
路 由 | 


图 3.16 ”Docker 使 用 到 的 与 Linux 网 络 有 关 的 主要 技术 


1. 网 络 的 命名 空间 


为 了 文 持 网 络 协议 栈 的 多 个 实例 ，Linux 在 网 络 栈 中 引入 了 网 络 命 
名 空间 (Network Namespace) ， 这 些 独立 的 协议 栈 被 隔离 到 不 同 的 命 
名 空间 中 。 处 于 不 同 命 名 空间 的 网 络 栈 是 完全 隔离 的 ， 彼 此 之 间 无 法 通 
信 ， 束 好 像 两 个 “平行 宇宙 ”。 通 过 这 种 对 网 络 资源 的 隅 离 ， 残 能 在 一 个 








宿主 机 上 虚拟 多 个 不 同 的 网 络 环境 。 而 Docker 也 正 是 利用 了 网 络 的 命名 
空间 特性 ， 实 现 了 不 同 容器 之 间 网 络 的 隔离 。 








在 Linux 的 网 络 命名 空间 内 可 以 有 自己 独立 的 路 由 表 及 独立 的 
Iptables/Netfilter 设 置 来 提供 包 转 发 、NAT 及 IP 包 过 滤 等 功能 





为 了 隔离 出 独立 的 协议 栈 ， 需 要 纳入 命名 空间 的 元 素 有 进程 、 套 接 

、 网 络 设 备 等 。 进 程 创建 的 套 接 字 必须 属于 某 个 命名 空间 ， 套 接 字 的 
oo 名 空间 内 进行 。 同 样 ， 网 络 设 备 也 必须 属于 某 个 命名 空 
间 。 因 为 网 络 设备 属于 公共 资源 ， 所 以 可 以 通过 修改 属性 实现 在 命名 空 
间 之 间 移 动 。 当 然 ， 是 否 允许 移动 和 设备 的 特征 有 关 。 








让 我 们 稍微 深入 Linux 操 作 系 统 内 部 ， 看 它 是 如 何 实现 网 络 命名 空 
间 的 ， 这 也 会 对 理解 后 面 的 概念 有 帮助 。 


1) 网 络 合 名 空间 的 实现 


Linux 的 网 络 协议 栈 是 十 分 复杂 的 ， 为 了 文 持 独立 的 协议 栈 ， 相 关 
的 这 些 全 局 变量 都 必须 修改 为 协议 栈 私有 。 最 好 的 办 法 就 是 让 这 些 全 局 
变量 成 为 一 个 Net Banie pace e E 然后 为 协议 栈 的 函数 调用 加 
入 一 个 Namespace 参 数 。 这 就 是 Linux 实 现 网 络 命名 空间 的 核心 。 


同时 ， 为 了 保证 对 已经 开发 的 应 用 程序 及 内 核 代 码 的 兼容 性 ， 内 核 
代码 隐 式 地 使 用 了 命名 空间 内 的 变量 。 我 们 的 程序 如 果 没 有 对 命名 空间 
的 特殊 需求 ， 那 么 不 需要 写 额 外 的 代码 ， 网 络 命 名 空间 对 应 用 程序 而 言 
是 透明 的 。 


在 建 并 了 新 的 网 络 命 名 空间 ， 并 将 条 个 进程 天 联 到 这 个 网 络 命名 空 
间 后 ， 就 出 现 了 类 似 于 如 图 3.17 所 示 的 内 核 数据 结 构 ， 所 有 网 站 栈 变 量 














都 放 入 了 网 络 命 名 空间 的 数据 结构 中 。 这 个 网 络 命名 空间 是 属于 它 的 进 
时 组 私有 的 ， 和 其 他 进程 组 不 冲突 。 








新 生成 的 私有 命名 空间 只 有 回环 lo 设备 (而 且 是 停止 状态 ) ， 其 他 
设备 默认 都 不 存在 ， 如 果 我 们 需要 ， 则 要 一 一 手工 建立 。Docker 容 右 中 
的 各 类 网 络 栈 设备 都 是 Docker Daemon 在 启动 时 自动 创建 和 配置 的 。 





所 有 的 网 络 设备 (物理 的 或 虚拟 接口 、 桥 等 在 内 核 里 都 叫 作 
NetDevice) 都 只 能 属于 一 个 命名 空间 。 当 然 ， 通 常 物理 的 设备 (连接 
实际 硬件 的 设备 ) 只 能 关联 到 root 这 个 命名 空间 中 。 虚 拟 的 网 络 设备 

(虚拟 的 以 太 网 接口 或 者 虚拟 网 口 对 〉 则 可 以 被 创建 并 关联 到 一 个 给 定 
的 命名 空间 中 ， 而 且 可 以 在 这 些 命名 空间 之 间 移 动 。 





进程 





图 3.17 命名 空间 内 核 结 构 





前 面 我 们 提 到 ， 由 于 网 络 命名 空间 代表 的 是 一 个 独立 的 协议 栈 ， 所 
以 它们 之 间 是 相互 隔离 的 ， 彼 此 无 法 通信 ， 在 协议 栈 内 部 都 看 不 到 对 
方 。 那 么 有 没有 办 法 打破 这 种 限制 ， 让 处 于 不 同 命名 空间 的 网 络 相 互通 
信 ， 甚 全 和 外 部 的 网 络 进行 通信 昵 ? 答案 就 是 “Veth 设 备 对 ”。“Veth 设 





备 对 ”的 一 个 重要 作用 就 是 打通 互相 看 不 到 的 协议 栈 之 间 的 壁 特 ， 它 就 
像 一 个 管子 ， 一 端 连 着 这 个 网 络 命名 空间 的 协议 栈 ， 一 端 连 着 另 一 个 网 
络 命名 空间 的 协议 栈 。 所 以 如 果 想 在 两 个 命名 空间 之 间 进 行 通信 ， 就 必 
须 有 一 个 Veth 设 备 对 。 后 面 我 们 会 介绍 如 何 操作 Veth 设 备 对 来 打通 不 同 
命名 空间 之 间 的 网 络 。 











2) 网 络 命名 空间 操作 
下 面 列举 一 些 网 络 命名 空间 的 操作 。 


我 们 可 以 使 用 Linux iproute2 系 列 配置 工具 中 的 卫 命 令 来 操作 网 络 命 


名 空间 。 注 意 ， 这 个 命令 需要 由 root 用 户 运 行 。 
创建 一 个 命名 空间 : 
ip netns add <name> 
在 命名 空间 内 执行 命令 : 
ip netns exec <name><command> 
如 果 想 执行 多 个 命令 ， 则 可 以 先进 入 内 部 的 sh， 然 后 执行 : 


ip netns exec <name> bash 


之 后 就 是 在 新 的 命名 空间 内 进行 操作 了。 退出 到 外 面 的 命名 空间 


时 ， 请 输入 “exit”。 


3) 网 络 命名 空间 的 一 些 技巧 


操作 网 络 命名 空间 时 的 一 些 实用 技巧 如 下 。 


我 们 可 以 在 不 同 的 网 络 命名 空间 之 间 转 移 设 备 ， 例 如 下 面 会 提 到 的 
Veth 设 备 对 的 转移 。 因 为 一 个 设备 只 能 属于 一 个 命名 空间 ， 所 以 转移 后 
在 这 个 命名 空间 内 就 看 不 到 这 个 设备 了 了。 具体 哪些 设备 能 够 转移 到 不 同 
的 命名 空间 呢 ? 在 设备 里 面 有 一 个 重要 的 属性 : 

NETIF_F_ETNS_ LOCAL， 如 果 这 个 属性 为 “on”， 则 不 能 转移 到 其 他 命 
名 空间 内 。Veth 设 备 属于 可 以 转移 的 设备 ， 而 很 多 其 他 设备 如 lo 设备 、 
vxlan 设 备 、ppp 设 备 、bridge 设 备 等 都 是 不 可 以 转移 的 。 人 至 于 将 无 法 转 
移 的 设备 移动 到 别 的 命名 空间 的 操作 ， 则 会 得 到 无 效 参数 的 错误 提示 。 





# ip link set brO netns ns1 


RTNETLINK answers: Invalid argument 


如 何 知道 这 些 设 备 是 否 可 以 转移 呢 ? AY MEH ethol LAA : 


# ethtool -k bro 


netns-local: on [fixed] 


netns-local 的 值 是 on， 就 说 明 不 可 以 转移 ， 和 否则 可 以 。 


2.Veth 设 备 对 








引入 Veth 设 备 对 是 为 了 在 不 同 的 网 络 命名 空间 之 间 进 行 通 信 ， 利 用 
它 可 以 直接 将 两 个 网 络 命名 空间 连接 起 来 。 由 于 要 连接 两 个 网 络 命 名 空 
间 ， 所 以 Veth 设 备 都 是 成 对 出 现 的 ， 很 像 一 对 以 太 网 卡 ， 并 且 中 间 有 一 
根 直 连 的 网 线 。 既 然 是 一 对 网 卡 ， 那 么 我 们 将 其 中 一 端 称 为 男 一 并 的 
peer。 在 Veth 设 备 的 一 器 发 送 数据 时 ， 它 会 将 数据 直接 发 送 到 另 一 端 ， 





并 触及 为 一 端的 接收 操作 。 


整个 Veth 的 实现 非常 简单 ， 有 兴趣 的 读者 可 以 参考 源 代 
码 “drivers/net/veth.c” 的 实现 。 图 3.18 是 Veth 设 备 对 的 示意 图 。 
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图 3.18 ”eth 设备 对 示意 图 
1) Veth 设 备 对 的 操作 命令 


接 下 来 看 看 如 何 创建 Veth 设 备 对 ， 如 何 连接 到 不 同 的 命名 空间 ， 并 
设置 它们 的 地 址 ， 让 它们 通信 。 


创 | 建 Veth 设 备 对 


ip link add vethO type veth peer name veth1 


创建 后 ， 可 以 查看 veth 设 备 对 的 信息 。 使 用 ip link show 命 令 查 看 所 
有 网 络 接口 : 


# ip link show 

1: lo: <LOOPBACK, UP, LOWER_UP> mtu 65536 qdisc noqueue sti 
Link/loopback: 00:00:00:00:00:00 brd 00:00:00:00:00:' 

2: eno16777736: <BROADCAST,MULTICAST,UP, LOWER_UP> mtu 15 
link/ether 00:0c:29:cf:1a:2e brd ff: ff: ff: ff: ff: fF 

3: docker0: <NO-CARRIER, BROADCAST, MULTICAST, UP> mtu 1500 

link/ether 56:84:7a:fe:97:99 brd ff: ff: ff: ff: ff: fF 

19: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop sta 

link/ether 7e:4a:ae:41:a3:65 brd ff: ff: ff: ff: ff: fF 

20: vethO: <BROADCAST,MULTICAST> mtu 1500 qdisc noop sta 

link/ether ea:da:85:a3:75:8a brd ff: ff: ff: ff: ff: fF 


看 到 了 吧 ， 有 两 个 设备 生成 了 ， 一 个 是 veth0， 它 的 peer 是 veth1。 


现在 这 两 个 设备 都 在 自己 的 命名 空间 内 ， 那 怎么 能 行 昵 ? 好 了 ， 如 
果 将 Veth 看 作 有 两 个 头 的 网 线 ， 那 么 我 们 将 另 一 个 头 甩 给 另 一 个 命名 空 
间 吧 : 


ip link set vethi netns netns1 





这 时 可 在 外 面 这 个 命名 空间 内 看 两 个 设备 的 情况 


# ip link show 

1: lo: <LOOPBACK, UP, LOWER_UP> mtu 65536 qdisc noqueue sti 
Link/loopback: 00:00:00:00:00:00 brd 00:00:00:00:00:'! 

2: eno16777736: <BROADCAST,MULTICAST,UP, LOWER_UP> mtu 15 
link/ether 00:0c:29:cf:1a:2e brd ff: ff: ff: ff: ff: fF 


3: docker0: <NO-CARRIER, BROADCAST, MULTICAST, UP> mtu 1500 
link/ether 56:84:7a:fe:97:99 brd ff: ff: ff: ff: fF: ff 
20: vethO: <BROADCAST,MULTICAST> mtu 1500 qdisc noop sta 
link/ether ea:da:85:a3:75:8a brd ff: ff: ff: ff: fF: ff 





ARI —TvethOns S, CEDIR- TREI, -SREE 
经 转移 到 为 一 个 网 络 命名 空间 了。 


在 netns1 网 络 命 名 空间 中 可 以 看 到 veth1l 设 备 了 了， 符合 预期 。 


# ip netns exec netns1 ip link show 

1: lo: <LOOPBACK, UP, LOWER_UP> mtu 65536 qdisc noqueue sti 
Link/loopback: 00:00:00:00:00:00 brd 00:00:00:00:00:| 

19: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop sta 

link/ether 7e:4a:ae:41:a3:65 brd ff: ff: ff: ff: ff: fF 





现在 看 到 的 结果 是 ， 两 个 不 同 的 命名 空间 各 自 有 一 个 Veth 的 “网 线 
头 ”， 各 显示 为 一 个 Device 〈 在 Docker 的 实现 里 面 ， 它 除了 将 Veth 放 入 容 
器 内 ， 还 将 它 的 名 字 改 成 了 eth0， 简 直 以 假 乱 真 ， 你 以 为 它 是 一 个 本 地 
网 卡 吗 ) 。 








现在 可 以 通信 了 吗 ? 不 行 ， 因 为 它们 还 没有 任何 地 址 ， 现 在 我 们 来 
给 它们 分 配 IP 地 址 吧 : 


ip netns exec netns1 ip addr add 10.1.1.1/24 dev veth1 


ip addr add 10.1.1.2/24 dev vetho 


再 局 动 它们 : 


ip netns exec netns1 ip link set dev veth1 up 


ip link set dev vethO up 








现在 两 个 网 络 命名 空间 可 以 互相 通信 了 : 


# ping 10.1.1.1 

PING10.1.1.1 (10.1.1.1) 56(84) bytes of data. 

64 bytes from 10.1.1.1: icmp_seq=1 tt1=64 time=0.035 ms 
64 bytes from 10.1.1.1: icmp_seq=2 ttl=64 time=0.096 ms 
AC 

--- 10.1.1.1 ping statistics --- 

2 packets transmitted, 2 received, 0% packet loss, time 


rtt min/avg/max/mdev = 0.035/0.065/0.096/0.031 ms 


# ip netns exec netnsi ping 10.1.1.2 

PING10.1.1.2 (10.1.1.2) 56(84) bytes of data. 

64 bytes from 10.1.1.2: icmp_seq=1 ttl=64 time=0.045 ms 
64 bytes from 10.1.1.2: icmp_seq=2 ttl=64 time=0.105 ms 
AC 

--- 10.1.1.2 ping statistics --- 

2 packets transmitted, 2 received, 0% packet loss, time 


rtt min/avg/max/mdev = 0.045/0.075/0.105/0.030 ms 





人 至此， 两 个 网 络 命名 空间 之 间 就 完全 通 了 。 


至 此 我 们 就 能 够 理解 Veth 设 备 对 的 原理 和 用 法 了 。 在 Docker 内 部 ， 
Veth 设 备 对 也 是 联系 容器 到 外 面 的 重要 设备 ， 离 开 它 是 不 行 的 。 





2) Veth 设 备 对 如 何 查 看 对 端 
我 们 在 操作 Veth 设 备 对 的 时 候 有 一 些 实用 技巧 ， 如 下 所 示 。 


一 旦 将 Veth 设 备 对 的 peer 端 放 入 男 一 个 命名 空间 ， 我 们 在 本 命名 空 
间 内 就 看 不 到 它 了 。 那 么 我 们 怎么 知道 这 个 Veth 对 的 对 端 在 哪里 呢 ， 也 
就 是 说 它 到 底 连 接 到 哪个 别 的 命名 空间 呢 ? 可 以 使 用 ethtool 工 具 来 查看 
( 当 网 络 命 名 空间 特别 多 的 时 候 ， 这 可 不 是 一 件 很 容易 的 事情 〉。 











首先 我 们 在 一 个 命名 空间 中 查询 Veth 设 备 对 端 接口 在 设备 列表 中 的 
序列 号 : 


ip netns exec netnsi ethtool -S vethi 
NIC statistics: 


peer_ifindex: 5 


45 A Fs Sis A Be BC PS eS, REAA as 4 28 Td 
查看 序列 号 5 代表 什么 设备 : 


ip netns exec netns2 ip link | grep 5 <-- 我 们 只 关注 序 ; 


vetho 


WI, FATA Pos Asie S, ‘ExevethO, EII — im 
目 然 就 是 另 一 个 命名 空间 中 的 veth1 了 ， 因 为 它们 互 为 peer。 


3. 网 桥 


Linux 可 以 文 持 很 多 不 同 的 端口 ， 这 些 端口 之 间 当 然 应 该 能 够 通 





信 ， 如 何 将 这 些 端口 连接 起 来 并 实现 类 似 交换 机 那样 的 多 对 多 通信 呢 ? 
这 就 是 网 桥 的 作用 了 。 网 桥 是 一 个 二 层 网 络 设备 ， 可 以 解析 收发 的 报 

文 ， 读 取 目 标 MAC 地 址 的 信息 ， 和 自己 记录 的 MAC 表 结合 ， 来 决策 报 
文 的 转发 端口 。 为 了 实现 这 些 功能 ， 网 桥 会 学 习 源 MAC 地 址 〈 二 层 网 

桥 转 发 的 依据 就 是 MAC 地 址 ) 。 在 转发 报 文 的 时 候 ， 网 桥 只 需要 向 特 
定 的 网 络 接口 进行 转发 ， 从 而 避免 不 必要 的 网 络 交 互 。 如 果 它 遇 到 一 个 
自己 从 未 学 习 到 的 地 址 ， 就 无 法 知道 这 个 报 文 应 该 从 哪个 网 口 设备 转 

发 ， 于 是 只 好 将 报 文 广播 给 所 有 的 网 络 设备 端口 ( 报 文 来 源 的 那个 端口 
除外 ) 。 





在 实际 网 络 中 ， 网 络 拓扑 不 可 能 永久 不 变 。 如 果 设 备 移 动 到 另 一 个 
端口 上 ， 而 它 没 有 发 送 任何 数据 ， 那 么 网 桥 设 备 就 无 法 感知 到 这 个 变 
化 ， 络 末 网 桥 还 是 癌 原 来 的 端口 转发 数据 包 ， 在 这 种 情况 下 数据 束 会 于 
失 。 所 以 网 桥 还 要 对 学 习 到 的 MAC 地 址 表 加 上 超时 时 间 (默认 为 5 分 
钟 ) 。 如 果 网 桥 收 到 了 对 应 端口 MAC 地 址 回 发 的 包 ， 则 重 置 超时 时 
间 ， 奋 则 过 了 超时 时 间 后 ， 就 认为 那个 设备 己 经 不 在 那个 端口 上 了 ， 它 
束 会 重新 广播 发 送 。 








在 Linux 的 内 部 网 络 栈 里 面 实现 的 网 桥 设 备 ， 作 用 和 上 面 的 描述 相 
同 。 过 去 Linux 主 机 一 般 部 只 有 一 个 网 卡 ， 现 在 多 网 卡 的 机 器 越 来 越 
多 ， 而 且 还 有 很 多 虚拟 的 设备 存在 ， 所 以 Linux 的 网 桥 提供 了 这 些 设备 
之 间 互 相 转 发 数据 的 二 层 设备 。 











Linux 内 核 支 持 网 口 的 桥接 (目前 只 支持 以 太 网 接口 )。 但 是 与 单 
纯 的 交换 机 不 同 ， 交 换 机 只 是 一 个 三 层 设备 ， 对 于 接收 到 的 报 文 ， 要么 
转发 ， 要 么 丢 和 并 。 运 行 着 Linux 内 核 的 机 器 本 身 就 是 一 全 主机， 有 可 能 
是 网 络 报 文 的 目的 地 ， 其 收 到 的 报 文 除 了 转发 和 丢弃 ， 还 可 能 被 送 到 网 
络 协议 栈 的 上 层 〔 网 络 层 ) ， 从 而 被 目 己 〈 这 人 台 主 机 本 身 的 协议 栈 ) 消 











化 ， 所 以 我 们 既 可 以 把 网 桥 看 作 一 个 二 层 设备 ， 也 可 以 看 作 一 个 三 层 设 


1) Linux 网 桥 的 实现 


Linux 内 核 是 通过 一 个 虚拟 的 网 桥 设备 (Net Device) 来 实现 桥接 
的 。 这 个 虚拟 设备 可 以 绑 定 若干 个 以 太 网 接口 设备 ， 从 而 将 它们 桥接 起 
来 。 如 图 3.19 所 示 ， 这 种 Net Device 网 桥 和 普通 的 设备 不 同 ， 最 明显 的 
一 个 特性 是 它 还 可 以 有 一 个 IP 地 址 。 


dev_queve_xmit netif_receive_skb ] 


tod. bakes ] NICdevice drivers | 





图 3.19 ”网 桥 的 位 置 


如 图 3.19 所 示 ， 网 桥 设 备 br0 绑 定 了 eth0 和 eth1。 对 于 网 络 协议 栈 的 
上 层 来 说 ， 只 看 得 到 br0。 因 为 桥接 是 在 数据 链 路 层 实现 的 ， 上 层 不 需 
要 关心 桥接 的 细节 ， 于 是 协议 栈 上 层 需要 发 送 的 报 文 被 送 到 br0， 网 桥 
设备 的 处 理 代 码 判断 报 文 该 被 转发 到 eth0 还 是 eth1， 或 者 两 者 如 转发 ; 
反 过 来 ， 从 eth0 或 从 eth1 接 收 到 的 报 文 被 提交 给 网 桥 的 处 理 代 码 ， 在 这 


里 会 判断 报 文 应 该 说 转 发 、 于 弃 还 是 提交 到 协议 栈 上 层 。 


而 有 了 时 eth0、eth1l 也 可 能 会 作为 报 文 的 源 地 址 或 目的 地 址 ， 直 接 参 
与 报 文 的 发 送 与 接收 ， 从 而 绕 过 网 桥 。 


2) 网 桥 的 常用 操作 命令 





Docker 自 动 完成 了 对 网 桥 的 创建 和 维护 。 为 了 进一步 理解 网 桥 ， 下 
面 举 几 个 常用 的 网 桥 操 作 例 子 ， 对 网 桥 进行 手工 操作 : 





#brctl addbr xxxxx 就 是 新 增 一 个 网 桥 


之 后 可 以 增加 端口 ， 在 Linux 中 ， 一 个 端口 其 实 就 是 一 个 物理 网 
卡 。 将 物理 网 卡 和 网 桥 连 接 起 来 : 


#brctl addif xxxxx ethx 


网 桥 的 物理 网 卡 作为 一 个 端口 ， 由 于 在 链 路 层 工 作 ， 就 不 再 需要 卫 
地 址 了 ， 这 样 上 面 的 耳 地 址 目 然 失效 : 


#ifconfig ethx 0.0.0.0 


给 网 桥 配置 一 个 IP 地 址 ; 


#ifconfig brxxx XXX.XXX.XXX.XXX 


这 样 网 桥 就 有 了 一 个 IP 地 址 ， 而 连接 到 上 面 的 网 卡 就 是 一 个 纯 链 路 
层 设备 了 。 


4.Iptables/Netfilter 


我 们 知道 ，Linux 网 络 协 议 栈 非 第 蜗 效 ， 同 时 比较 复 森 。 如 果 我 们 
希望 在 数据 的 处 理 过 程 中 对 关心 的 数据 进行 一 些 操 作 该 怎么 做 呢 ? 
Linux 提 供 了 一 僚机 制 来 为 用 户 实现 目 定 义 的 数据 包 处 理 过 程 。 


在 Linux 网 络 协 议 栈 中 有 一 组 回调 函数 挂 接 点 ， 通 过 这 些 挂 接 点 挂 
接 的 钧 子 函数 可 以 在 Linux 网 络 栈 处 理 数据 包 的 过 程 中 对 数据 包 进 行 一 
些 操 作 ， 例 如 过 滤 、 人 和 修改、 丢弃 等 。 整 个 挂 接点 技术 叫 作 Netfilter 和 
Iptables. 





Netfilter 负 责 在 内 核 中 执行 各 种 挂 接 的 规则 ， 运 行 在 内 核 模式 中 ; 
而 Iptables 是 在 用 户 模式 下 运行 的 进程 ， 负 责 协 助 维护 内 核 中 Netfilter 的 
各 种 规则 表 。 通 过 二 者 的 配合 来 实现 整个 Linux 网 络 协议 栈 中 灵活 的 数 
据 包 处 理 机 制 。 





Netfilter 可 以 挂 接 的 规则 点 有 5 个 ， 如 图 3.20 中 的 深 色 椭圆 所 示 。 
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图 3.20 ”Netfilter 挂 接点 
1) 规则 表 Table 


这 些 挂 接 点 能 挂 接 的 规则 也 分 不 同 的 类 型 (也 就 是 规则 表 
Table) ， 我 们 可 以 在 不 同类 型 的 Table 中 加 入 我 们 的 规则 。 目 前 主要 支 
持 的 Table 类 型 为 : 


e RAW; 

e MANGLE; 
e NAT; 

e FILTER. 


上 述 4 个 Table〈 规 则 链 ) 的 优先 级 是 RAW 最 高 ，FILTER 最 低 。 


在 实际 应 用 中 ， 不 同 的 挂 接点 需要 的 规则 类 型 通常 不 同 。 例 如 ， 在 





Input 的 挂 接点 上 明显 不 需要 FILTER 过 滤 规 则 ， 因 为 根据 目标 地 址 ， 已 
经 选择 好 本 机 的 上 层 协 议 栈 了 ， 所 以 无 须 再 挂 接 FILTER 过 小 规则 。 目 
前 Linux 系 统 文 持 的 不 同 挂 接 点 能 挂 接 的 规则 类 型 如 图 3.21 所 示 。 









Iptables 防 火 墙 默认 的 规则 表 、 链 结构 
第 1 条 规则 
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图 3.21 不 同 表 的 挂 接 点 


当 Linux 协 议 栈 的 数据 处 理 运行 到 挂 接点 时 ， 它 会 依次 调用 挂 接点 
上 所 有 的 挂钩 函数 ， 直 到 数据 包 的 处 理 结 果 是 明确 地 接受 或 者 拒绝 。 


2) 处 理 规 则 
每 个 规则 的 特性 都 分 为 以 下 几 部 分 : 


。 表 类 型 (准备 干什么 事情 〉; 

。 什么 挂 接点 (什么 时 候 起 作用 )〉; 

。 匹配 的 参数 是 什么 《〈 针 对 什么 样 的 数据 包 ) ; 

。 匹配 后 有 什么 动作 《匹配 后 具体 的 操作 是 什么 ) 。 


表 类 型 和 什么 挂 接点 在 前 面 已 经 介绍 了 ， 现 在 我 们 看 看 匹配 的 参数 


和 匹配 后 的 动作 。 
(1) 匹配 的 参数 


匹配 的 参数 用 于 对 数据 包 或 者 TCP 数 据 连接 的 状态 进行 匹配 。 当 有 
多 个 条 件 存 在 时 ， 筷 们 一 起 起 作用 ， 来 达到 只 针对 某 部 分 数据 进行 修改 
的 目的 。 和 常见 的 匹配 参数 有 : 





。 流入 、 注 出 的 网 络 接 口 ; 
s 来 源 、 目的 地 址 ; 
。 协 议 类 型 ， 


。 来 源 、 目 的 端口 。 
(2) 匹配 后 的 动作 


一 旦 有 数据 匹配 上 ， 就 会 执行 相应 的 动作 。 动 作 类 型 既 可 以 是 标准 
的 预定 义 的 几 个 动作 ， 也 可 以 是 目 定 义 的 模块 注册 的 动作 ， 或 者 是 一 个 
新 的 规则 链 ， 以 便 更 好 地 组 织 一 组 动作 。 


3) Iptables 命 令 


Iptables 命 令 用 于 协助 用 户 维护 各 种 规则 。 我 们 在 使 用 Kubernetes、 
Docker 的 过 程 中 ， 通 常 都 会 去 查看 相关 的 Netfilter 配 置 。 这 里 只 介绍 如 
何 查 看 规则 表 ， 详 细 的 介绍 请 参照 Linux 的 Iptables 帮 助 文档 。 





查看 系统 中 己 有 的 规则 的 方法 如 下 。 


。 iptables-save: 按照 命令 的 方式 打印 Iptables 的 内 容 。 
。 Iptables-vnL: 以 另 一 种 格式 显示 Netfilter 表 的 内 容 。 


5. 路 由 


Linux 系 统 包 含 一 个 完整 的 路 由 功能 。 当 了 P 层 在 处 理 数 据 发 送 或 者 
转发 的 时 候 ， 会 使 用 路 由 表 来 决定 发 往 哪 里 。 通 常情 况 下 ， 如 果 主 机 与 
日 的 主机 直接 相连 ， 那 么 主机 可 以 直接 发 送 IP 报 文 到 目的 主机 ， 这 个 过 
程 比 较 简 单 。 例 如 ， 通 过 点 对 点 的 链接 或 通过 网 络 共享 ， 如 果 主 机 与 目 
的 主机 没有 直接 相连 ， 那 么 主机 会 将 IP 报 文 发 送 给 默认 的 路 由 器 ， 然 后 
由 路 由 器 来 决定 往 哪 发送 IP 报 文 。 


路 由 功能 由 IP 层 维护 的 一 张 路 由 表 来 实现 。 当 主机 收 到 数据 报 文 
时 ， 它 用 此 表 来 决策 接 下 来 应 该 做 什么 操作 。 当 从 网 络 侧 接 收 到 数据 报 
文 时 ，IP 层 首先 会 检查 报 文 的 卫 地 址 是 否 与 主机 自身 的 地 址 相同 。 如 果 
数据 报 文中 的 IP 地 址 是 主机 自身 的 地 址 ， 那 么 报 文 将 被 发 送 到 传输 层 相 
应 的 协议 中 去 。 如 果 报 文中 的 耳 地 址 不 是 主机 自身 的 地 址 ， 并 且 主 机 配 
置 了 路 由 功能 ， 那 么 报 文 将 被 转发 ， 否 则 ， 报 文 将 被 丢 大 。 











路 由 表 中 的 数据 一 般 是 以 条 目 形式 存在 的 。 一 个 典型 的 路 由 表 条 目 
通 第 包含 以 下 主要 的 条 目 项 。 








(1) 目的 了 地 址 ， 此 字段 表示 目标 的 了 地 址 。 这 个 I 地 址 可 以 是 某 
台 主 机 的 地 址 ， 也 可 以 是 一 个 网 络 地 址 。 如 果 这 个 条 目 包含 的 是 一 个 主 
机 地 址 ， 那 么 它 的 主机 ID 将 被 标记 为 非 零 ， 如 果 这 个 条 目 包含 的 是 一 个 
网 络 地 址 ， 那 么 它 的 主机 ID 将 被 标记 为 零 。 


(2) 下 一 个 路 由 器 的 耳 地 址 : 为 什么 采用 “下 一 个 ”的 说 法 ， 是 因 
为 下 一 个 路 由 需 并 不 总 是 最 终 的 目的 路 由 器 ， 它 很 可 能 是 一 个 中 间 路 由 
器 。 条 目 给 出 下 一 个 路 由 需 的 地 址 用 来 转发 从 相应 接口 接收 到 的 IP 数 据 
报 文 。 


(3) 标志 : 这 个 字段 提供 了 力 一 组 重要 信息 ， 例 如 目的 IP 地 址 是 
一 个 主机 地 址 还 是 一 个 网 络 地址 。 此 外 ， 从 标志 中 可 以 得 知 下 一 个 路 由 
器 是 一 个 真实 路 由 圳 还 是 一 个 直接 相连 的 接口 。 


(4) 网 络 接口 规范 : 为 一 些 数 据 报 文 的 网 络 接口 规范 ， 该 规范 将 
与 报 文 一 起 被 转发 。 


在 通过 路 由 表 转 发 时 ， 如 果 任 何 条 目的 第 1 个 字段 完全 匹配 目的 IP 
地 址 (主机 〉 或 部 分 匹配 条 目的 IP 地 址 (网络) ， 那 么 它 将 指示 下 一 个 
路 由 器 的 人 PP 地址 。 这 是 一 个 重要 的 信息 ， 因 为 这 些 信息 直接 告诉 主机 
(具备 路 由 功能 的 ) 数据 包 应 该 转发 到 哪个 “下 一 个 路 由 器 ”去 。 而 条 目 
中 的 所 有 其 他 字段 将 提供 更 多 的 辅助 信息 来 为 路 由 转发 做 决定 。 








如 果 没 有 找到 一 个 完全 匹配 的 卫 ， 那 么 就 接着 搜索 相 匹配 的 网 络 
ID。 如 果 找 到 ， 那 么 该 数据 报 文 会 被 转 发 到 指定 的 路 由 器 上 。 aa 
出 ， 网 络 上 的 所 有 主机 都 通过 这 个 路 由 表 中 的 单个 〈 这 个 ) 条 目 进行 管 
Lis 


如 果 上 述 两 个 条 件 都 不 匹配 ， 那 么 该 数据 报 文 将 被 转发 到 一 个 默认 
路 由 器 上 。 
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法 被 转发 。 任 何 无 法 投递 的 数据 报 文 都 将 产生 一 个 ICMP 主 机 不 可 达 或 
ICMP 网 络 不 可 达 的 错误 ， 并 将 此 错误 返回 给 生成 此 数据 报 文 的 应 用 程 
序 。 


1) 路 由 表 的 创建 





Linux 的 路 由 表 人 至 少 包 括 两 个 表 (当局 用 集 略 路 由 的 时 候 ， 还 会 有 


其 他 表 ) : 一 个 是 LOCAL， 男 一 个 是 MAIN。 在 LOCAL 表 中 会 包含 所 
有 的 本 地 设备 地 址 。LOCAL 路 由 表 是 在 配置 网 络 设备 地 址 时 自动 创建 
的 。LOCAL 表 用 于 供 Linux 协 议 栈 识别 本 地 地 址 ， 以 及 进行 本 地 各 个 不 
同 网 络 接口 之 间 的 数据 转发 。 


可 以 通过 下 面 的 命令 查看 LOCAL 表 的 内 容 : 


# ip route show table local type local 

10.1.1.0 dev flannelO proto kernel scope host src 10.: 
127.0.0.0/8 dev lo proto kernel scope host src 127.0.| 
127.0.0.1 dev lo proto kernel scope host src 127.0.0.: 
172.17.42.1 dev docker proto kernel scope host src 17: 


192.168.1.128 dev eno16777736 proto kernel scope host 


MAIN 表 用 于 各 类 网 络 IP 地 址 的 转发 。 它 的 建 并 既 可 以 使 用 静态 配 
置 生 成 ， 也 可 以 使 用 动态 路 由 发 现 协议 生成 。 动 态 路 由 发 现 协 议 一 般 使 
用 组 播 功能 来 通过 发 送 路 由 发 现 数据 ， 动 态 地 交换 和 获取 网 络 的 路 由 信 
息 ， 并 更 新 到 路 由 表 中 。 





Linux 下 支持 路 由 发 现 协 议 的 开源 软件 有 许多 ， 和 常用 的 有 Quagga、 
Zebra 等 。 第 4 章 会 介绍 使 用 Quagga 动 态 容器 路 由 发 现 的 机 制 来 实现 
Kubernetes 的 网 络 组 网 。 





2) 路 由 表 的 碍 看 
我 们 可 以 使 用 ip route list 命 令 查 看 当前 的 路 由 表 。 


# ip route list 


192.168.6.0/24 dev eno16777736 proto kernel scope link 


在 上 面 的 例子 代码 中 ， 只 有 一 个 子 网 的 路 由 ， 源 地 址 是 
192.168.6.140 (AHL) ， 目 标 地 址 是 192.168.6.0/24 网 段 的 数据 ， 都 将 通 
过 eth0 接 口 设 备 发 送出 去 。 


Netstat-m 是 男 一 个 查看 路 由 表 的 工具 : 





# netstat -rn 


Kernel IP routing table 


Destination Gateway Genmask Flag: 
0.0.0.0 192.168.6.2 0.0.0.0 UG 
192.168.6.0 0.0.0.0 255.255.255.0 U 


在 它 显示 的 信息 中 ， 如 果 标 志 是 U， 则 说 明 是 可 达 路 由 ; 如 果 标 志 
是 G， 则 说 明 这 个 网 络 接口 连接 的 是 网 天 ， 否 则 说 明 是 直 连 主机 。 





3.7.3 Docker 的 网 络 实现 


标准 的 Docker 支 持 以 下 4 类 网 络 模 式 。 


e host 模 式 : 使 用 --net=host 指 定 

e container 模 式 : 使 用 --net=container: NAME_or_ID 指 定 
e none 模 式 : 使 用 --net=none 指 定 

。 bridge 模 式 : 使 用 --net=bridge 指 定 ， 为 默认 设置 。 


在 Kubernetes 管 理 模式 下 ， 通 常 只 会 使 用 bridge 模 式 ， 所 以 本 节 只 介 
绍 bridge 模 式 下 Docker 是 如 何 支持 网 络 的 。 


在 bridge 模 式 下 ，Docker Daemon 第 1 次 启动 时 会 创建 一 个 虚拟 的 网 
桥 ， 默 认 的 名 字 是 docker0， 然 后 按照 RPC1918 的 模型 ， 在 私有 网 络 空间 
中 给 这 个 网 桥 分 配 一 个 子 网 。 针 对 由 Docker 创 建 出 来 的 每 一 个 容器 ， 都 
会 创建 一 个 虚拟 的 以 太 网 设备 (Veth 设 备 对 ) ， 其 中 一 端 关联 到 网 桥 
上 ， 另 一 端 使 用 Linux 的 网 络 命 名 空间 技术 ， 了 映射 到 容 髓 内 的 eth0 设 备 ， 
然后 从 网 桥 的 地 址 段 内 给 eth0 接 口 分 配 一 个 耳 地 址 。 


如 图 3.22 所 示 就 是 Docker 的 默认 桥接 网 络 模型 。 





图 3.22 ”默认 的 Docker 网 络 桥接 模型 


其 中 ipl 是 网 桥 的 IP 地 址 ，Docker Daemon 会 在 几 个 备 选 地 址 段 里 给 
它 选 一 个 ， 通 常 是 172 开 头 的 一 个 地 址 。 这 个 地 址 和 主机 的 耳 地 址 是 不 
重 闪 的 。ip2 是 Docker 在 启动 容器 的 时 候 ， 在 这 个 地 址 段 随 机 选择 的 一 
个 没有 使 用 的 人 P 地 址 ，Docker 占 用 它 并 分 配给 了 被 启动 的 容器 。 相 应 的 


MAC 地 址 也 根据 这 个 IP 地 址 ， 在 02: 42: ac: 11: 00: 00 和 02: 42: 
ac: 11: ff: 任 的 范围 内 生成 ， 这 样 做 可 以 确保 不 会 有 ARP 的 冲突 。 


局 动 后 ，Docker 还 将 Veth 对 的 名 字 上 映射 到 了 eth0 网 络 接口 。ip3 残 是 
主机 的 网 卡 地 址 。 


在 一 般 情况 下 ，ip1、ip2 和 ip3 是 不 同 的 IP 段 ， 所 以 在 默认 不 做 任何 
特殊 配置 的 情况 下 ， 在 外 部 是 看 不 到 ipl1 和 ip2 的 。 


这 样 做 的 结果 就 是 ， 同 一 全 机 器 内 的 容 圳 之 间 可 以 相互 通信 。 不 同 
主机 上 的 容 右 不 能 够 相互 通信 。 实 际 上 它们 甚至 有 可 能 会 在 相同 的 网 络 
地 址 范围 内 《不 同 的 主机 上 的 docker0 的 地 址 段 可 能 是 一 样 的 ) 。 





为 了 证 它们 路 节点 互相 通信 ， 就 必须 在 主机 的 地 址 上 分 配 端 口 ， 然 
后 通过 这 个 端口 路 由 或 代理 到 容器 上 。 这 种 做 法 显然 意味 着 一 定 要 在 容 
器 之 间 小 心 讶 慎 地 协调 好 端口 的 分 配 ， 或 者 使 用 动态 端口 的 分 配 技术 。 
在 不 同 应 用 之 间 协 调 好 端口 分 配 古 十 分 困难 的 事情 ， 特 别 是 集群 水 平 扩 
展 的 时 候 。 而 动态 的 端口 分 配 也 会 带 来 高 度 复杂 性 ， 例 如 : 每 个 应 用 程 
序 都 只 能 将 端口 看 作 一 个 符号 〈 因 为 是 动态 分 配 的 ， 无 法 提前 设置 ) 。 
而 且 API Server 也 要 在 分 配 完 后 ， 将 动态 端口 插入 到 配置 的 合适 位 置 。 
另外 ， 服 务 也 必须 能 互相 之 间 找 到 对 方 等 。 这 些 都 是 Docker 的 网 络 模型 
在 路 主机 访问 时 面临 的 问题 。 

















1) 查看 Docker 启 动 后 的 系统 情况 


我 们 已 经 知道 ，Docker 网 络 在 bridge 模 式 下 Docker Daemon 启 动 时 创 
建 docker0 网 桥 ， 并 在 网 桥 使 用 的 网 段 为 容器 分 配 IP。 让 我 们 看 看 实际 的 
操作 。 





在 刚刚 局 动 DockerDaemon 并 且 还 没有 局 动 任 何 容 器 的 时 候 ， 网 络 
协议 栈 的 配置 情况 如 下 : 


# systemctl start docker 
# ip addr 
1: lo: <LOOPBACK, UP, LOWER_UP> mtu 65536 qdisc noqueue sti 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:0 
inet 127.0.0.1/8 scope host lo 
valid_lft forever preferred_lft forever 
inet6 ::1/128 scope host 
valid_lft forever preferred_lft forever 
2: eno16777736: <BROADCAST,MULTICAST,UP, LOWER_UP> mtu 15 
link/ether 00:0c:29:14:3d:80 brd ff: ff: ff: ff: ff: fF 
inet 192.168.1.133/24 brd 192.168.1.255 scope global 
valid_lft forever preferred_lft forever 
inet6 fe80::20c:29ff:fe14:3d80/64 scope link 
valid_lft forever preferred_lft forever 
3: docker0: <NO-CARRIER, BROADCAST,MULTICAST,UP> mtu 1500 
link/ether 02:42:6e:af:0e:c3 brd ff: ff: ff: ff: ff: fF 
inet 172.17.42.1/24 scope global dockerg 


valid_lft forever preferred_lft forever 


# iptables-save 

# Generated by iptables-save v1.4.21 on Thu Sep 24 17:11 
*nat 

:PREROUTING ACCEPT [7:878] 

: INPUT ACCEPT [7:878] 


:OUTPUT ACCEPT [3:536] 

:POSTROUTING ACCEPT [3:536] 

:DOCKER - [0:0] 

-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER 

-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL 
-A POSTROUTING -s 172.17.0.0/16 ! -o docker® -j MASQUERAI 
COMMIT 

# Completed on Thu Sep 24 17:11:04 2015 

# Generated by iptables-save v1.4.21 on Thu Sep 24 17:11 
*filter 

: INPUT ACCEPT [133:11362] 

:FORWARD ACCEPT [0:0] 

:OUTPUT ACCEPT [37:5000] 

:DOCKER - [0:0] 

-A FORWARD -o docker@ -j DOCKER 

-A FORWARD -o docker® -m conntrack --ctstate RELATED, EST, 
-A FORWARD -i dockerO ! -o docker0 -j ACCEPT 

-A FORWARD -i dockerO -o dockerO -j ACCEPT 

COMMIT 

# Completed on Thu Sep 24 17:11:04 2015 


可 以 看 到 ，Docker 创 建 了 docker0 网 桥 ， 并 添加 了 Iptables 规 则 。 
docker0 网 桥 和 Iptables 规 则 都 处 于 root 命 名 空间 中 。 通 过 解读 这 些 规则 ， 
我 们 发 现 ， 在 还 没有 启动 任何 容器 时 ， 如 果 启 动 了 Docker Daemon, H 
么 它 就 已 经 做 好 了 通信 的 准备 。 对 这 些 规则 的 说 明 如 下 。 











(1) 在 NAT 表 中 有 3 条 记录 ， 前 两 条 匹配 生效 后 ， 都 会 继续 执行 





DOCKER 链 ， 而 此 时 DOCKER 链 为 空 ， 所 以 前 两 条 只 是 做 了 个 框架 ， 
并 没有 实际 效果 。 


(2) NAT 表 第 3 条 的 含义 是 ， 知 本 地 发 出 的 数据 包 不 是 发 往 
docker0 的 ， 即 是 发 往 主 机 之 外 的 设备 的 ， 都 需要 进行 动态 地 址 修改 
(MASQUERADE) ， 将 源 地 址 从 容器 的 地 址 〈172 段 ) 修改 为 宿主 机 
网 卡 的 耳 地 址 ， 之 后 就 可 以 发 送 给 外 面 的 网 络 了 。 





(3) 在 FILTER 表 中 ， 第 1 条 也 是 一 个 框架 ， 因 为 后 继 的 DOCKER 
链 是 空 的 。 


(4) 在 FILTER 表 中 ， 第 3 条 是 说 ，docker0 发 出 的 包 ， 如 果 需 要 
Forward 到 非 docker0 的 本 地 IP 地 址 的 设备 ， 则 是 允许 的 ， 这 样 ，docker0 
设备 的 包 惑 可 以 根据 路 由 规则 中 转 到 宿主 机 的 网 卡 设备 ， 从 而 访问 外 面 
的 网 络 。 


(5) FILTER 表 中 ， 第 4 条 是 说 ，docker0 的 包 还 可 以 中 转 给 docker0 
本 吴 ， 即 连接 在 docker0 网 桥 上 的 不 同 容 器 之 间 的 通信 也 是 允许 的 。 


(6) FILTER 表 中 ， 第 2 条 是 说 ， 如 果 接 收 到 的 数据 包 属 于 以 前 已 
经 建立 好 的 连接 ， 那 么 允许 直接 通过 。 这 样 接收 到 的 数据 包 自 然 又 走 回 
docker0， 并 中 转 到 相应 的 容器 。 


除了 这 些 Netfilter 的 设置 ，Linux 的 ip_forward 功 能 也 被 Docker 
Daemon 打 开 了 : 


# cat /proc/sys/net/ipv4/ip_forward 
1 


另外 ， 我 们 还 可 以 看 到 刚刚 启动 Docker 后 的 Route 表 ， 和 局 动 前 没 
有 什么 不 同 : 


# ip route 

default via 192.168.1.2 dev eno16777736 proto static m 
172.17.0.0/16 dev docker proto kernel scope link = src 

192.168.1.0/24 dev eno16777736 proto kernel scope link 


192.168.1.0/24 dev eno16777736 proto kernel scope link 





2) 得 看 容器 局 动 后 的 情况 〈 容 器 无 端口 映射 ) 





刚才 我 们 看 了 Docker 服 务 启动 后 的 网 络 情况 。 现 在 ， 我 们 局 动 一 个 
Registry 容 器 后 不 使 用 任何 并口 镜 像 参 数 ) ， 看 一 下 网 络 堆栈 部 分 相 
关 的 变化 : 


docker run --name register -d registry 
# ip addr 
1: lo: <LOOPBACK, UP, LOWER UP> mtu 65536 qdisc noqueue sti 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:0 
inet 127.0.0.1/8 scope host lo 
valid_lft forever preferred_lft forever 
inet6 ::1/128 scope host 
valid_lft forever preferred_lft forever 
2: enoi16777736: <BROADCAST,MULTICAST,UP, LOWER_UP> mtu 15! 
link/ether 00:0c:29:c8:12:5f brd ff: ff: ff: ff: ff: fF 
inet 192.168.1.132/24 brd 192.168.1.255 scope global 


valid_lft forever preferred_lft forever 


inet6 fe80::20c:29ff:fec8:125f/64 scope link 
valid_lft forever preferred_lft forever 
3: docker0: <NO-CARRIER, BROADCAST, MULTICAST, UP> mtu 1500 
link/ether 02:42:72:79:b8:88 brd ff: ff: ff: ff: fF: ff 
inet 172.17.42.1/24 scope global dockerg 
valid_lft forever preferred_lft forever 
inet6 fe80::42:7aff:fe79:b888/64 scope link 
valid_lft forever preferred_lft forever 
13: veth2dc8bbd: <BROADCAST, MULTICAST, UP, LOWER_UP> mtu 1 
link/ether be:d9:19:42:46:18 brd ff: ff: ff: ff: fF: ff 
inet6 fe80: :bcd9:19ff:fe42:4618/64 scope link 


valid_lft forever preferred_lft forever 


# iptables-save 

# Generated by iptables-save v1.4.21 on Thu Sep 24 18:21 
*nat 

:PREROUTING ACCEPT [14:1730] 

: INPUT ACCEPT [14:1730] 

: OUTPUT ACCEPT [59:4918] 

:POSTROUTING ACCEPT [59:4918] 

:DOCKER - [0:0] 

-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER 

-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL 
-A POSTROUTING -s 172.17.0.0/16 ! -o docker® -j MASQUERAI 
COMMIT 

# Completed on Thu Sep 24 18:21:04 2015 


# Generated by iptables-save v1.4.21 on Thu Sep 24 18:21 


*filter 

: INPUT ACCEPT [2383:211572] 

:FORWARD ACCEPT [0:0] 

: OUTPUT ACCEPT [2004: 242872] 

:DOCKER - [0:0] 

-A FORWARD -o docker@ -j DOCKER 

-A FORWARD -o docker® -m conntrack --ctstate RELATED, EST, 
-A FORWARD -i dockerO ! -o docker0 -j ACCEPT 
-A FORWARD -i dockerO -o dockerO -j ACCEPT 
COMMIT 

# Completed on Thu Sep 24 18:21:04 2015 


# ip route 

default via 192.168.1.2 dev eno16777736 proto static m 
172.17.0.0/16 dev docker proto kernel scope link src 
192.168.1.0/24 dev eno16777736 proto kernel scope link 
192.168.1.0/24 dev eno16777736 proto kernel scope link 


可 以 看 到 如 下 情况 


(1) 宿主 机 器 上 的 Netfilter 和 路 由 表 都 没有 变化 ， 说 明 在 不 进行 端 
口 映 射 时 ，Docker 的 默认 络 是 没有 特殊 处 理 的 。 相 关 的 NAT 和 
FILTER 两 个 Netfilter 链 还 是 空 的 。 


(2) 宿主 机 上 的 Veth 对 已 经 建立 ， 并 连接 到 了 容器 内 。 


我 们 再 次 进入 刚刚 启动 的 容器 内 ， 看 看 网 络 栈 是 什么 情况 。 容 右 内 
部 的 了 P 地 址 和 路 由 如 下 : 


# docker exec -ti 24981a750a1a bash 
[root@24981a750ala /]# ip route 
default via 172.17.42.1 dev etho 
172.17.0.0/16 dev ethO proto kernel scope link src 17: 
[root@24981a750ala /]# ip addr 
1: lo: <LOOPBACK, UP, LOWER_UP> mtu 65536 qdisc noqueue sti 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:0I 
inet 127.0.0.1/8 scope host lo 
valid_lft forever preferred_lft forever 
inet6 ::1/128 scope host 
valid_lft forever preferred_lft forever 
22: ethO: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdi: 
link/ether 02:42:ac:11:00:0a brd ff: ff: ff: ff: ff: fF 
inet 172.17.0.10/16 scope global eth0O 
valid_lft forever preferred_lft forever 
inet6 fe80::42:acff:fel1:a/64 scope link 


valid_lft forever preferred_lft forever 


我 们 可 以 看 到 ， 默 认 停 止 的 回环 设备 lo 已 经 被 启动 ， 外 面 答 主机 连 
接 进 来 的 Veth 设 备 也 被 命名 成 了 eth0， 并 且 已 经 配置 了 地 址 
172.17.0.10。 








路 由 信息 表 包 含 一 条 到 docker0 的 子 网 路 由 和 一 条 到 docker0 的 默认 
路 由 。 











3) 查看 容器 启动 后 的 情况 (容器 有 端口 映射 ) 


下 面 ， 我 们 用 带 端口 映射 的 命令 月 动 registry: 


docker run --name register -d -p 1180:5000 registry 


在 启动 后 查看 Iptables 的 变化 。 


# iptables-save 

# Generated by iptables-save v1.4.21 on Thu Sep 24 18:45 
*nat 

: PREROUTING ACCEPT [2:236] 

:INPUT ACCEPT [0:0] 

: OUTPUT ACCEPT [0:0] 

:POSTROUTING ACCEPT [0:0] 

:DOCKER - [0:0] 

-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER 

-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL 
-A POSTROUTING -s 172.17.0.0/16 ! -o docker® -j MASQUERAI 
-A POSTROUTING -s 172.17.0.19/32 -d 172.17.0.19/32 -p tc 
-A DOCKER ! -i docker® -p tcp -m tcp --dport 1180 -j DNA 
COMMIT 

# Completed on Thu Sep 24 18:45:13 2015 

# Generated by iptables-save v1.4.21 on Thu Sep 24 18:45 
*filter 

: INPUT ACCEPT [54:4464] 

:FORWARD ACCEPT [0:0] 

: OUTPUT ACCEPT [41:5576] 

:DOCKER - [0:0] 

-A FORWARD -o docker0 -j DOCKER 

-A FORWARD -o docker® -m conntrack --ctstate RELATED, EST, 


-A FORWARD -i dockerO ! -o docker0 -j ACCEPT 

-A FORWARD -i docker0 -o docker® -j ACCEPT 

-A DOCKER -d 172.17.0.19/32 ! -i dockerO -o dockerO -pt 
COMMIT 

# Completed on Thu Sep 24 18:45:13 2015 


从 新 增 的 规则 可 以 看 出 ，Docker 服 务 在 NAT 和 FILTER 两 个 表 内 添 
加 的 两 个 DOCKER 子 链 都 是 给 端口 映射 用 的 。 例 如 本 例 中 我 们 需要 把 外 
面 宿主 机 的 1180 端 口 映 射 到 容器 的 5000 端 口 。 通 过 前 面 的 分 析 我 们 知 
道 ， 无 论 是 宿主 机 接收 到 的 还 是 宿主 机 本 地 协议 栈 发 出 的 ， 目 标 地 址 是 
本 地 卫 地 址 的 包 都 会 经 过 NAT 表 中 的 DOCKER 子 链 。Docker 为 每 一 个 端 
口 映 射 都 在 这 个 链 上 增加 了 到 实际 容器 目标 地 址 和 目标 端口 的 转换 。 


经 过 这 个 DNAT 的 规则 修改 后 的 IP 包 ， 会 重新 经 过 路 由 模块 的 判断 
进行 转发 。 由 于 目标 地 址 和 端口 已 经 是 容器 的 地 址 和 端口 ， 所 以 数据 自 
然 束 送 到 了 docker0 上 ， 从 而 送 到 对 应 的 容器 内 部 。 


当然 在 Forward 时 ， 也 需要 在 Docker 子 链 中 添加 一 条 规则 ， 如 果 目 
标 端口 和 地 址 是 指定 容器 的 数据 ， 则 人 允许 通过 。 





在 Docker 按 照 端口 映射 的 方式 尼 动 容器 时 ， 主 要 的 不 同 就 是 上 述 
Iptables 部 分 。 而 容器 内 部 的 路 由 和 网 络 设备 ， 都 和 不 做 端口 映射 时 一 
样 ， 没 有 任何 变化 。 


4) Docker 的 网 络 局 限 


我 们 从 Docker 对 Linux 网 络 协议 栈 的 操作 可 以 看 到 ，Docker 一 开始 
没有 考虑 到 多 主机 互联 的 网 络 解决 方案 。 


Docker 一 直 以 来 的 理念 都 是 “简单 为 美 ”， 几 乎 所 有 尝试 Docker 的 
人 ， 都 被 它 “ 用 法 简单 ， 功 能 强大 ”的 特性 所 吸引 ， 这 也 是 Docker 迅 速 走 
红 的 一 个 原因 。 


我 们 都 知道 ， 虚 拟 化 技术 中 最 为 复杂 的 部 分 就 是 虚拟 化 网 络 技 术 ， 
即使 是 单纯 的 物理 网 络 部 分 ， 也 是 一 个 门槛 很 高 的 技能 领域 ， 通 党 只 被 
少数 网 络 工程 师 所 掌握 ， 所 以 我 们 可 以 理解 ， 结 合 了 物理 网 络 的 虚拟 网 
络 技术 会 有 多 难 了 。 在 Docker 之 前 ， 所 有 接触 过 OpenStack 的 人 的 心里 
都 有 一 个 难以 释怀 的 阴影 ， 那 就 是 它 的 网 络 问题 ， 于 是 ，Docker 明 智 地 
避 开 这 个 “ 雷 区 ”， 让 其 他 专业 人 员 去 用 现 有 的 虚拟 化 网 络 技 术 解 决 
Docker 主 机 的 互联 问题 ， 以 免 让 用 户 觉 得 Docker 太 难 了 ， 从 而 放弃 学 习 
和 使 用 Docker。 


Docker 成 名 以 后 ， 重 新 开始 重视 网 络 解决 方案 ， 收 购 了 一 家 Docker 
网 络 解决 方案 公司 Socketplane， 原 因 在 于 这 家 公司 的 产品 广 受 好 
评 ， 但 有 趣 的 是 Socketplane 的 方案 就 是 以 Open vSwitch 为 核心 的 ， 其 还 
为 Open vSwitch 提 供 了 Docker 镜 像 ， 以 方便 部 区 程序 。 之 后 ，Docker 开 
启 了 一 个 “宏伟 ”的 虚拟 化 网 络 解决 方案 一 一 Libnetwork， 如 图 3.23 所 示 
是 其 概念 图 。 
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图 3.23 ”Libnetwork 概 念 图 


这 个 概念 网 没有 了 卫 ， 也 没有 了 路 由 ， 已 经 颠覆 了 我 们 的 网 络 音 识 
了 ， 对 于 不 怎么 懂 网 络 的 大 多 数 人 来 说 ， 它 的 确 很 有 诱惑 力 ， 未 来 是 否 
会 对 虚拟 化 网 络 的 模型 产生 深远 冲击 我 们 还 不 得 而 知 ， 但 当前 ， 它 仅仅 
是 Docker 官 方 的 一 次 “尝试 ”。 

针对 目前 Docker 的 网 络 实现 ，Docker 使 用 的 Libnetwork 组 件 只 是 将 
Docker 平 台中 的 网 络 子 系统 模块 化 为 一 个 独立 库 的 简单 尝试 ， 离 成 熟 和 
完善 还 有 一 段 距离 。 





所 以 ， 直 到 现在 ， 仍 然 没 有 来 自 Docker 官 方 的 可 以 用 于 生产 实践 中 
的 多 主机 网 络 解决 方案 。 


3.7.4 Kubernetes 的 网 络 实现 





在 实际 的 业务 场景 中 ， 业 务 组件 之 间 的 关系 十 分 复杂 ， 特 别 是 微服 
务 概念 的 推进 ， 应 用 部 署 的 粒度 更 加 细小 和 灵活 。 为 了 支持 业务 应 用 组 
件 的 通信 联系 ，Kubernetes 网 络 的 设计 主要 致力 于 解决 以 下 场景 。 





(1) 容器 到 容器 之 间 的 直接 通信 ，。 
(2) 抽象 的 Pod 到 Pod 之 间 的 通信 。 
(3) Pod 到 Service 之 间 的 通信 。 


(4) 集群 外 部 与 内 部 组 件 之 间 的 通信 。 








其 中 第 3 条 、 第 4 条 我 们 在 之 前 的 章节 里 都 讲述 过 ， 本 节 中 我 们 对 更 
为 基础 的 第 1 条 与 第 2 条 进行 深入 分 析 和 讲解 。 





1. 容 絮 到 容器 的 通信 


在 同一 个 Pod 内 的 容器 (Pod 内 的 容器 是 不 会 跨 宿 主机 的 ) 共享 同一 
个 网 络 命名 空间 ， 共 享 同一 个 Linux 协 议 栈 。 所 以 对 于 网 络 的 各 类 操 
作 ， 就 和 它们 在 同一 台 机 器 上 一 样 ， 它 们 甚至 可 以 用 localhost 地 址 访问 
彼此 的 端口 。 





这 么 做 的 结果 是 简单 、 安 全 和 高 效 ， 也 能 减少 将 已 经 存在 的 程序 从 
物理 机 或 者 虚拟 机 移植 到 容器 下 运行 的 难度 。 在 容 右 技术 出 来 之 前 ， 其 


实 大 家 早 就 积累 了 如 何在 一 台 机 器 上 运行 一 组 应 用 程序 的 经 验 ， 例 如 ， 
如 何 让 端口 不 冲突 ， 以 及 如 何 让 客户 端 发 现 它们 等 。 


我 们 来 看 一 下 Kubernetes 是 如 何 利 用 Docker 的 网 络 模型 的 。 





图 3.24 中 的 阴影 部 分 就 是 在 Node 上 运行 着 的 一 个 Pod 实 例 。 在 我 们 
的 例子 中 ， 容 器 就 是 图 3.24 中 的 容器 1 和 容器 2。 容 器 1 和 容器 2 共享 了 一 
个 网 络 的 命名 空间 ， 共 享 一 个 命名 空间 的 结果 就 是 它们 好 像 在 一 台 机 器 
上 运行 似 的 ， 它 们 打开 的 端口 不 会 有 冲突 ， 可 以 直接 使 用 Linux 的 本 地 
IPC 进 行 通信 【例如 消息 队列 或 者 管道 ) 。 其 实 这 和 传统 的 一 组 普通 程 
序 运 行 的 环境 是 完全 一 样 的 ， 传 统 的 程序 不 需要 针对 网 络 做 特别 的 修改 
就 可 以 移植 了 。 它 们 之 间 的 互相 访问 只 需要 使 用 localhost 就 可 以 。 例 
如 ， 如 果 容 器 2 运行 的 是 MySQL， 那 么 容器 1 使 用 localhost: 3306 就 能 
接 访 问 这 个 运行 在 容器 2 上 的 MySQL 了 。 




















图 3.24 ”Kubernetes 的 Pod 网 络 模 型 


2.Pod 之 间 的 通信 


我 们 看 了 同一 个 Pod 内 的 容器 之 间 的 通信 和 情况， 再 看 看 Pod 之 间 的 通 


每 一 个 Pod 都 有 一 个 真实 的 全 局 IP 地 址 ， 同 一 个 Node 内 的 不 同 Pod 之 
间 可 以 直接 采用 对 方 Pod 的 外地 址 通信 ， 而 且 不 需要 使 用 其 他 发 现 机 
制 ， 例 如 DNS、Consul 或 者 etcd。 











Pod 容 器 既 有 可 能 在 同一 个 Node 上 运行 ， 也 有 可 能 在 不 同 的 Node 上 
运行 ， 所 以 通信 也 分 为 两 类 : 同一 个 Node 内 的 Pod 之 间 的 通信 和 不 同 
Node 上 的 Pod 之 间 的 通信 。 


1) 同一 个 Node 内 的 Pod 之 间 的 通信 
我 们 看 一 下 同一 个 Node 上 的 两 个 Pod 之 间 的 关系 ， 如 图 3.25 所 示 。 


可 以 看 出 ，Pod1 和 Pod2 都 是 通过 Veth 连 接 在 同一 个 docker0 网 桥 上 
的 ， 它 们 的 IP 地 址 IP1、IP2 都 是 从 docker0 的 网 段 上 动态 获取 的 ， 它 们 和 
网 桥 本 身 的 IP3 是 同一 个 网 段 的 。 


另外 ， 在 Pod1、Pod2 的 Linux 协 议 栈 上 ， 默 认 路 由 都 是 docker0 的 地 
址 ， 也 就 是 说 所 有 非 本 地 地 址 的 网 络 数 据 ， 都 会 被 默认 发 送 到 docker0 
网 桥 上 ， 由 docker0 网 桥 直接 中 转 。 


综 上 所 述 ， 由 于 它们 都 关联 在 同一 个 docker0 网 桥 上 ， 地 址 段 相 
同 ， 所 以 它们 之 间 是 能 直接 通信 的 。 
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图 3.25 ”同一 个 Node 内 的 Pod 关 系 
2) 不 同 Node 上 的 Pod 之 间 的 通信 


Pod 的 地 址 是 与 docker0 在 同一 个 网 段 内 的 ， 我 们 知道 docker0 网 段 与 
宿主 机 网 卡 是 两 个 完全 不 同 的 IP 网 段 ， 并 且 不 同 Node 之 间 的 通信 只 能 通 
过 宿主 机 的 物理 网 卡 进行 ， ae eee 同 Node 上 的 Pod 容 器 之 
间 的 通信 ， 就 必须 想 办 法 通过 主机 的 这 个 耿 地 址 来 进行 寻 址 和 通信 。 


另 一 方面 ， 这 些 动态 分 配 且 藏 在 docker0 之 后 的 所 谓 “ 私 有 ”ITP 地 址 也 
是 可 以 找到 的 。Kubernetes 会 记录 所 有 正在 运行 Pod 的 IP 分 配 信息 ， 并 将 
这 些 信息 保存 在 etcd 中 (作为 Service 的 Endpoint) 。 这 些 私 有 IP 信 息 对 
于 Pod 到 Pod 的 通信 也 是 十 分 重要 的 ， 因 为 我 们 的 网 络 模型 要 求 Pod 到 
Pod 使 用 私有 也 进行 通信 。 所 以 首先 要 知道 这 些 IP 是 什么 。 





之 前 提 到 ，Kubernetes 的 网 络 对 Pod 的 地 址 是 平面 的 和 直达 的 ， 所 以 
这 些 Pod 的 卫 规 划 也 很 重要 ， 不 能 有 冲突 。 只 要 没有 冲突 ， 我 们 束 可 以 
想 办 法 在 整个 Kubernetes 的 集群 中 找到 它 。 


综 上 所 述 ， 要 想 文 持 不 同 Node 上 的 Pod 之 间 的 通信 ， 就 要 达到 两 个 
AP: 


(1) 在 整个 Kubernetes 集 群 中 对 Pod 的 了 也 分 配 进 行规 划 ， 不 能 有 溃 
突 ; 


(2) 找到 一 种 办 法 ， 将 Pod 的 也 和 所 在 Node 的 卫 关 联 起 来 ， 通 过 这 
个 关联 让 Pod 可 以 互相 访问 。 


根据 条 件 1 的 要 求 ， 我 们 需要 在 部 署 Kubernetes 的 时 候 ， 对 docker0 
的 IP 地 址 进行 规划 ， 保 证 每 一 个 Node 上 的 docker0 地 址 没有 冲突 。 我 们 
可 以 在 规划 后 手工 配置 到 每 个 Node 上 ， 或 者 做 一 个 分 配 规则 ， 由 安装 的 
程序 自己 去 分 配 占 用 。 例 如 Kubernetes 的 网 络 增强 开源 软件 Flannel 就 能 
够 管理 资源 池 的 分 配 。 





根据 条 件 2 的 要 求 ，Pod 中 的 数据 在 发 出 时 ， 需 要 有 一 个 机 制 能 够 知 
道 对方 Pod 的 IP 地 址 挂 在 哪个 具体 的 Node 上 。 也 就 是 说 先 要 找到 Node 对 
应 宿主 机 的 了 P 地 址 ， 将 数据 发 送 到 这 个 宿主 机 的 网 卡 上 ， 然 后 在 宿主 机 
上 将 相应 的 数据 转 到 具体 的 docker0 上 。 一 旦 数据 到 达 窒 主机 Node， 则 
那个 Node 内 部 的 docker0 便 知道 如 何 将 数据 发 送 到 Pod。 如 图 3.26 所 示 。 


































































































图 3.26” 跨 Node 的 Pod 通 信 


在 图 3.26 中 ，IP1 对 应 的 是 Pod1，IP2 对 应 的 是 Pod2。Pod1 在 访问 
Pod2 时 ， 首 先 要 将 数据 从 源 Node 的 eth0 发 送出 去 ， 找 到 并 到 达 Node2 的 
eth0。 也 就 是 说 先 要 从 IP3 到 IP4， 之 后 才 是 IP4 到 IP2 的 递送 。 


在 谷歌 的 GCE 环 境 下 ，Pod 的 卫 管 理 〈 类 似 docker0) 、 分 配 及 它们 
之 间 的 路 由 打通 都 是 由 GCE 完 成 的 。Kubernetes 作 为 主要 在 GCE 上 面 运 
行 的 框架 ， 它 的 设计 是 假设 底层 已 经 具备 这 些 条 件 ， 所 以 它 分 配 完 地 址 
并 将 地 址 记录 下 来 就 完成 了 它 的 工作 。 在 实际 的 GCE 环 境 中 ，GCE 的 网 
络 组 件 会 读 取 这 些 信 息 ， 实 现 具 体 的 网 络 打 通 。 











而 在 实际 的 生产 中 ， 因 为 安全 、 费 用 、 合 规 等 种 种 原因 ， 
Kubernetes 的 客户 不 可 能 全 部 使 用 谷歌 的 GCE 环 境 ， 所 以 在 实际 的 私有 


云 环境 中 ， 除 了 部 署 Kubernetes 和 Docker， 还 需要 额外 的 网 络 配置 ， 甚 
至 通过 一 些 软件 来 实现 Kubernetes 对 网 络 的 要 求 。 做 到 这 些 后 ，Pod 和 
Pod 之 间 才 能 无 差别 地 透明 通信 。 


为 了 达到 这 个 目的 ， 开 源 界 有 不 少 应 用 来 增强 Kubernetes、Docker 
的 网 络 ， 在 后 面 的 章节 里 会 介绍 几 个 常用 的 组 件 和 它们 的 组 网 原理 。 


3.7.5 ”开源 的 网 络 组 件 


Kubernetes 的 网 络 模 型 假定 了 所 有 Pod 都 在 一 个 可 以 直接 连通 的 局 平 
的 网 络 空 间 中 。 这 在 GCE 里 面 是 现成 的 网 络 模 型 ，Kubernetes 假 定 这 个 
网 络 已 经 存在 。 而 在 私有 云 里 搭建 Kubernetes 集 群 ， 就 不 能 假定 这 种 网 
络 已 经 存在 了 了。 我们 需要 自己 实现 这 个 网 络 假设 ， 将 不 同 节点 上 的 
Docker 容 器 之 间 的 互相 访问 先 打 通 ， 然 后 运行 Kubernetes。 














目前 已 经 有 多 个 开源 组 件 文 持 这 个 网 络 模型 。 这 里 介绍 几 个 常见 的 
模型 ， 分 别 是 Flannel、Open vSwitch 及 直接 路 由 的 方式 。 
1.Flannel 


Flannel 之 所 以 可 以 搭建 Kubernetes 依 赖 的 底层 网 络 ， 是 因为 它 能 实 
现 以 下 两 点 。 


(1) 它 能 协助 Kubernetes， 给 每 一 个 Node 上 的 Docker 容 器 分 配 互 相 
不 冲突 的 卫 地 址 。 


(2) 它 能 在 这 些 了 地 址 之 间 建 立 一 个 履 辣 网 络 
(OverlayNetwork) ， 通 过 这 个 履 辣 网络， 将 数据 包 原 封 不 动 地 传递 到 
目标 容器 内 。 


通过 图 3.27 来 看 看 Flannel 是 如 何 实现 这 两 点 的 。 


可 以 看 到 ，Flannel 首 先 创建 了 一 个 名 为 flannel0 的 网 桥 ， 而 且 这 个 


网 桥 的 一 端 连接 docker0 网 酉 ， 另 一 端 连 接 一 个 叫 作 flanneld 的 服务 进 


程 。 


flanneld 进 程 并 不 简单 ， 它 首先 上 连 etcd， 利 用 etcd 来 管理 可 分 配 的 
IP 地 址 段 资源 ， 同 时 监控 etcd 中 每 个 Pod 的 实际 地 址 ， 并 在 内 存 中 建立 了 
一 个 Pod 节 点 路 由 表 ; 然后 下 连 docker0 和 物理 网 络 ， 使 用 内 存 中 的 Pod 
节点 路 由 表 ， 将 docker0 发 给 它 的 数据 包 包 装 起 来 ， 利 用 物理 网 络 的 连 
接 将 数据 包 投 弟 到 目标 flanneld 上 ， 从 而 完成 Pod 到 Pod 之 则 的 直接 的 地 
址 通信 。 


Flannel 之 间 的 底层 通信 协议 的 可 选 余地 很 多 ， 有 UDP、VxLan、 
AWS VPC 等 多 种 方式 ， 只 要 能 通 到 对 端的 Flannel 就 可 以 了 。 源 flanneld 
加 包 ， 目 标 flanneld 解 包 ， 最 终 docker0 看 到 的 就 是 原始 的 数据 ， 非 常 透 
明 ， 根 本 感觉 不 到 中 间 Flannel 的 存在 。 常 用 的 是 UDP。 








图 3.27 Flannel B] 


我 们 看 一 下 Flannel 是 如 何 做 到 让 为 不 同 Node 上 的 Pod 分 配 的 卫 不 产 
生 冲 突 的 。 其 实 想 到 Flannel 使 用 了 集中 的 etcd 存 储 就 很 容易 理解 了 。 它 
每 次 分 配 的 地 址 段 都 在 同一 个 公共 区 域 获取 ， 这 样 大 家 自然 能 够 互相 协 
调 ， 不 产生 冲突 了 。 而 且 在 Flannel 分 配 好 地 址 段 后 ， 后 面 的 事情 是 由 
Docker 完 成 的 ，Flannel 通 过 修改 Docker 的 启动 参数 将 分 配给 它 的 地 址 段 
传递 进去 。 





--bip=172.17.18.1/24 


通过 这 些 操 作 ，Flannel 就 控制 了 每 个 Node 上 的 docker0 地 址 段 的 地 
址 ， 也 就 保障 了 所 有 Pod 的 卫 地 址 在 同一 个 水 平 网 络 中 且 不 产生 冲突 
T; 


Flannel 完 美 地 实现 了 对 Kubernetes 网 络 的 支持 ， 但 是 它 引 入 了 多 个 
网 络 组 件 ， 在 网 络 通信 时 需要 转 到 flannel0 网 络 接口 ， 再 转 到 用 户 态 的 
flanneld 程 序 ， 到 对 端 后 还 需要 走 这 个 过 程 的 反 过 程 ， 所 以 也 会 引入 一 
些 网 络 的 时 延 损耗 。 





另外 ，EFlannel 模 型 默认 使 用 了 UDP 作为 底层 传输 协议 ，UDP 本 号 是 
非 可 靠 协 议 ， 昌 然 两 端的 TCP 实 现 了 可 徘 传输 ， 但 在 大 流量 、 局 并 发 应 
用 场景 下 还 需要 反复 测试 ， 确 保 没 有 问题 。 











2.Open vSwitch 


在 了 解 了 Flannel 后 ， 我 们 再 看 看 Open vSwitch 是 怎么 解决 上 述 两 个 
问题 的 。 


Open vSwitch 是 一 个 开源 的 虚拟 交换 机 软件 ， 有 点 儿 像 Linux 中 的 





bridge， 但 是 功能 要 复杂 得 多 。Open vSwitch 的 网 桥 可 以 直接 建立 多 种 
通信 通道 (隧道 ) ， 例 如 Open vSwitch with GRE/VxLAN。 这 些 通道 的 
建立 可 以 很 容易 地 通过 OVS 的 配置 命令 实现 。 在 Kubernetes、Docker 场 
景 下 ， 我 们 主要 是 建立 L3 到 L3 的 隧道 。 举 一 个 例子 来 看 看 Open vSwitch 
with GRE/VxLAN 的 网 络 架 构 ， 如 图 3.28 所 示 。 





docker131 192.168.18.131 docker128 192 168 18 128 











图 3.28 OVS with GREE K] 


首先 ， 为 了 避免 Docker 创 建 的 docker0 地 址 产生 冲突 (因为 Docker 
Daemon 启 动 且 给 docker0 选 择 子 网 地 址 时 只 有 几 个 备 选 列 表 ， 很 容易 产 
生 冲 突 )， 我 们 可 以 将 docker0 网 桥 删 除 ， 手 动 建立 一 个 Linux 网 桥 ， 然 
后 手动 给 这 个 网 桥 配 置 耳 地址 范围 。 


其 次 ， 建 立 Open vSwitch 的 网 桥 ovs， 然 后 使 用 ovs-vsctl 命 令 给 ovs 网 
桥 增 加 gre 端 口 ， 添 加 gre 端 口 时 要 将 目标 连接 的 NodeIP 地 址 设置 为 对 端 
的 卫 地 址 。 对 每 一 个 对 问 耻 地址 都 需要 这 人 么 操作 《对 于 大 型 集群 网 络 ， 
这 可 是 个 体力 活 ， 要 做 自动 化 脚本 来 完成 ) 。 





最 后 将 ovs 的 网 桥 作 为 网 络 接口 ， 加 入 Docker 的 网 桥 上 〈docker0 或 
者 自己 手工 建立 的 新 网 桥 ) 。 


重启 ovs 网 桥 和 Docker 的 网 桥 ， 并 添加 一 个 Docker 的 地 址 段 到 


Docker 网 桥 的 路 由 规则 项 ， 就 可 以 将 两 个 容器 的 网 络 连 接 起 来 了 。 
1) 网 络 通信 过 程 


当 容 器 内 的 应 用 访问 男 一 个 容 右 的 地 址 时 ， 数 据 包 会 通过 容器 内 的 
默认 路 由 发 送 给 docker0 网 桥 。ovs 的 网 桥 是 作为 docker0 网 桥 的 端口 存在 
的 ， 它 会 将 数据 发 送 给 ovs 网 桥 。ovs 网 络 已 经 通过 配置 建立 了 和 其 他 ovs 
网 桥 的 GRE/VxLAN 隧 道 ， 自 然 能 将 数据 送 达 对 端的 Node， 并 送 往 
docker0 及 Pod。 








通过 新 增 的 路 由 项 ， 使 得 Node 节 点 本 身 的 应 用 的 数据 也 路 由 到 
docker0 网 桥 上 ， 和 刚才 的 通信 过 程 一 样 ， 自 然 也 可 以 访问 其 他 Node 上 
的 Pod。 


2) OVS with GRE/VxLAN 组 网 方式 的 特点 





OVS 的 优势 是 ， 作 为 开源 虚拟 交换 机 软件 ， 它 相对 比较 成 熟 和 稳 
定 ， 而 且 文 持 各 类 网 络 隧道 协议 ， 经 过 了 OpenStack 等 项 目的 考验 。 


另 一 方面 ， 在 前 面 介 绍 Flannel 的 时 候 可 知 Flannel 除 了 文 持 建立 履 疼 
网 络 (Overlay Network) ， 保 证 Pod 到 Pod 的 无 颖 通信 ， 还 和 
Kubernetes、Docker 架 构 体 系 结 紧密 。Flannel 能 够 感知 Kubemetes J 
Service， 动 态 维 护 自 己 的 路 由 表 ， 还 通过 etcd 来 协助 Docker 对 整 
Kubernetes 集 群 中 docker0 的 子 网 hie 。 而 我 们 在 使 用 OVS 的 a 候 ， 
很 多 事情 就 需要 手工 完成 了 。 





无 论 是 OVS 还 是 Flannel， 通 过 和 履 盖 网 络 提供 的 Pod 到 Pod 通 信 都 会 引 
入 一 些 额外 的 通信 开销 ， 如 果 是 对 网 络 依 赖 特别 重 的 应 用 ， 则 需要 评估 
对 业务 的 影响 。 


3. 直 接 路 由 


我 们 知道 ，docker0 网 桥 上 的 IP 地 址 在 Node 网 络 上 是 看 不 到 的 。 从 
一 个 Node 到 一 个 Node 内 的 docker0 是 不 通 的 。 因 为 它 不 知道 某 个 IP 地 址 
在 哪里 。 如 果 能 够 让 这 些 机 器 知道 对 端 docker0 地 址 在 哪里 ， 就 可 以 让 
这 些 docker0 互 相通 信 了 。 这 样 所 有 Node 上 运行 的 Pod 就 可 以 互相 通信 
Ja 


我 们 可 以 通过 部 署 MultiLayer Switch (MLS) 来 实现 这 一 点 ， 在 
MLS 中 配置 每 个 docker0 子 网 地 址 到 Node 地 址 的 路 由 项 ， 通 过 MLS 将 
docker0 的 也 寻 址 定 同 到 对 应 的 Node 节 点 上 。 





另外 ， 我 们 还 可 以 将 这 些 docker0 和 Node 的 匹配 关系 配置 在 Linux 操 
作 系 统 的 路 由 项 中 ， 这 样 通 信 发 起 的 Node 能 够 根据 这 些 路 由 信息 直接 找 
到 目标 Pod 所 在 的 Node， 将 数据 传输 过 去 。 如 图 3.29 所 示 。 
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图 3.29 直接 路 由 Pod 到 Pod 通 信 


我 们 在 每 个 Node 的 路 由 表 中 增加 对 方 所 有 docker0 的 路 由 项 。 


例如 Pod1 所 在 docker0 网 桥 的 IP 子 网 是 10.1.10.0，Node 的 地 址 为 
192.168.1.128; 而 Pod2 所 在 docker0 网 桥 的 卫 子 网 是 10.1.20.0，Node 的 地 
址 为 192.168.1.129。 


在 Node1 上 用 route ” add 命令 增加 一 条 到 Node2 上 docker0 的 静态 路 由 
规则 : 


route add -net 10.1.20.0 netmask 255.255.255.0 gw 192.16 


同样 ， 在 Node2 上 增加 一 条 到 Nodel 上 docker0 的 静态 路 由 规则 : 


route add -net 10.1.10.0 netmask 255.255.255.0 gw 192.16 


这 样 两 个 Node 之 间 的 Pod 就 可 以 互相 通信 了 ， 因 为 它们 发 出 的 数据 
包 经 过 本 地 Linux 的 路 由 规则 ， 能 将 数据 送 到 对 端的 Node。 


在 大 规模 集群 中 ， 在 每 个 Node 上 都 需要 配置 到 其 他 docker0/Node 的 
路 由 项 ， 会 带 来 很 大 的 工作 量 ; 并 且 在 新 增 机 器 时 ， 对 所 有 Node 都 需要 
修改 配置 ， 重 启 机 器 时 ， 如 果 docker0 的 地 址 有 变化 ， 则 也 需要 修改 所 
有 Node 的 配置 ， 这 显然 是 非常 复杂 的 。 





为 了 管理 这 些 动态 变化 的 docker0 地 址 ， 动 态 地 让 其 他 Node 都 感知 
到 它 ， 还 可 以 使 用 动态 路 由 发 现 协 议 来 同步 这 些 变化 。 运 行动 态 路 由 发 
现 协 议 代理 的 Node， 会 将 本 机 LOCAL 路 由 表 的 卫 地 址 通过 组 播 协议 发 
布 出 去 ， 同 时 监听 其 他 Node 的 组 播 包 。 通 过 这 样 的 信息 交换 ，Node 上 
的 路 由 规则 都 能 够 相互 学 习 到 。 当 然 ， 路 由 发 现 协议 本 号 还 是 很 复杂 
的 ， 感 兴趣 的 话 你 可 以 查阅 相关 的 规范 。 在 实现 这 些 动态 路 由 发 现 协议 
的 开源 软件 中 ， 常 用 的 有 Quagga、Zebra 等 。 下 面 简单 介绍 直接 路 由 的 
操作 过 程 。 








(1) 首先 手工 分 配 Docker bridge 的 地 址 ， 保 证 它们 在 不 同 的 网 段 
HERBS. EMEA ADocker Daemon 自 动 创建 的 docker0〔 因 为 我 
们 不 需要 它 的 自动 管理 功能 ) ， 而 是 单独 建立 一 个 bridge， 给 它 配置 规 
划 好 的 IP 地 址 ， 然 后 使 用 --bridge=XX 来 指定 网 桥 。 





(2) 然后 在 每 一 个 节点 上 运行 Quagga。 


完成 这 些 操 作 后 ， 我 们 很 快 就 能 得 到 一 个 Pod 和 Pod 和 直接 互相 访问 的 
环境 了 。 由 于 路 由 发 现 能 够 被 网 络 上 的 所 有 设备 接收 ， 所 以 如 果 网 络 上 


的 路 由 右 也 能 打开 RIP 协 议 选项 ， 则 能 够 学 习 到 这 些 路 由 信息 。 通 过 这 
些 路 由 器 ， 我 们 甚至 可 以 在 非 Node 节 点 上 使 用 Pod 的 IP 地 址 直接 访问 
Node 上 的 Pod。 


当然 ， 聪 明 的 你 还 会 有 新 的 疑问 : 这 样 做 的 话 ， 由 于 每 一 个 Pod 的 
地 址 都 会 被 路 由 发 现 协议 广播 出 去 ， 会 不 会 存在 路 由 表 过 大 的 情况 ? K 
际 上 ， 路 由 表 通 常 都 会 有 高 速 绥 存 ， 伍 找 速度 会 很 快 ， 不 会 对 性 能 产生 
太 大 的 有 影响。 当然， 如 果 你 的 集群 容量 在 数 干 台 Node 以 上 ， 则 仍然 需要 
测试 和 评估 路 由 表 的 效率 问题 。 








3.7.6 ”网 络 实战 


Docker 给 我 们 市 来 了 不 同 的 网 络 模 式 ， 而 Kubernetes 也 以 一 种 不 同 
的 方式 来 解决 这 些 网 络 模式 的 挑战 ， 但 是 其 方式 有 些 不 太 好 理解 ， 特 别 
是 对 于 刚 开始 接触 Kubernetes 的 网 络 的 开发 者 。 我 们 在 前 面 学 习 了 
Kubernetes、Docker 的 理论 ， 本 节 将 通过 一 个 完整 的 实验 ， 从 部 署 一 个 
Pod 开 始 ， 一 步 一 步 地 部 署 那些 Kubernetes 的 组 件 ， 来 剖析 Kubernetes 在 
网 络 层 是 如 何 实现 及 如 何 工 作 的 。 


这 里 使 用 虚拟 机 来 完成 实验 。 如 果 你 要 部 署 在 物理 机 器 上 ， 或 者 部 
署 在 云 服务 商 的 环境 下 ， 则 涉及 的 网 络 模型 很 可 能 稍微 有 所 不 同 。 不 
过 ， 从 网 络 角度 来 看 ，Kubernetes 的 机 制 是 类 似 且 一 致 的 。 


好 了 ， 来 看 看 我 们 的 实验 环境 ， 如 图 3.30 所 示 。 


192.168.1.129 192.168.1.130 


Node3 
192.168.1.131 


Kube master 
192.168.1.129 





图 3.30 ”实验 环境 
Kubernetes 的 网 络 模型 要 求 每 一 个 Node 上 的 容器 都 可 以 相互 访问 。 


默认 的 Docker 的 网 络 模型 提供 了 一 个 IP 地 址 段 是 172.17.0.0/16 的 
docker0 网 桥 。 每 一 个 容器 都 会 在 这 个 子 网 内 获得 IP 地 址 ， 并 且 将 
docker0 网 桥 的 IP 地 址 (172.17.42.1〉 作 为 其 默认 网 关 。 需 要 注意 的 是 
Docker 宿 主机 外 面 的 网 络 不 需要 知道 任何 关于 这 个 172.17.0.0/16 的 信息 
或 者 知道 如 何 连 接 到 它 内 部 ， 因 为 Docker 的 宿主 机 针对 容器 发 出 的 数 
据 ， 在 物理 网 卡 地 址 后 面 都 做 了 卫 伪 装 MASQUERADE ( 隐 舍 NAT) 。 
也 就 是 说 ， 在 网 络 上 看 到 的 任何 容器 数据 流 都 来 源 于 那 台 Docker 节 点 的 
物理 IP 地 址 。 这 里 所 说 的 网 络 都 是 指 连接 这 些 主机 的 物理 网 络 。 


这 个 模型 便于 使 用 ， 但 是 并 不 完美 ， 需 要 依赖 端口 映射 的 机 制 。 





在 Kubernetes 的 网 络 模型 中 ， 每 台 主 机 上 的 docker0 网 桥 都 是 可 以 被 
路 由 到 的 。 也 惑 是 说 ， 在 部 署 了 一 个 Pod 的 时 候 ， 在 同一 个 集群 内 ， 那 
台 主 机 的 外 面 可 以 直接 访问 到 那个 Pod， 并 不 需要 在 那 台 物理 主机 上 做 
端口 映射 。 综 上 所 述 ， 你 可 以 在 网 络 层 将 Kubernetes 的 节点 看 作 一 个 路 
由 器 。 如 果 我 们 将 实验 环境 改 画 成 一 个 网 络 图 ， 那 么 它 看 起 来 如 图 3.31 


所 示 。 
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图 3.31 实验 环境 网 络 图 


为 了 支持 Kubernetes 网 络 模 型 ， 我 们 采取 了 直接 路 由 的 方式 来 实 
现 ， 在 每 个 Node 上 配置 相应 的 静态 路 由 项 ， 例 如 在 192.168.1.129 这 个 
Node 上 我 们 配置 了 两 个 路 由 项 : 


#route add -net 10.1.20.0 netmask 255.255.255.0 gw 192.1 
#route add -net 10.1.30.0 netmask 255.255.255.0 gw 192.1 


KERE, BES a Se AY AS AEH XS Node (docker0 的 网 
PIP) 作为 它 的 默认 网 关 。 而 这 些 Node 节 点 〈 类 似 路 由 器 ) 都 有 其 他 
docker0 的 路 由 信息 ， 这 样 它们 融 能 够 相互 连通 了 。 








接 下 来 通过 一 些 实际 的 案例 ， 来 看 看 Kubernetes 在 不 同 的 场景 下 其 


网 络 部 分 到 底 做 了 什么 事情 。 
第 1 步 : 部 署 一 个 RC/Pod 


部 蜀 的 RC/Pod 描 述 文件 如 下 Cfrontend-controller.yaml) : 


apiVersion: vi 
kind: ReplicationController 
metadata: 
name: frontend 
labels: 
name: frontend 
spec: 
replicas: 1 
selector: 
name: frontend 
template: 
metadata: 
labels: 
name: frontend 
spec: 
containers: 
- name: php-redis 
image: kubeguide/guestbook-php-frontend 
env: 
- name: GET_HOSTS_FROM 


value: env 


ports: 
- containerPort: 80 


hostPort: 80 


为 了 便于 观察 ， 我 们 假定 在 一 个 空 的 Kubernetes 集 群 上 运行 ， 提 前 
清理 了 所 有 Replication Controller、Pod 和 其 他 Service: 


# kubectl get rc 

CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLIC, 
# 

# kubectl get services 

NAME LABELS : 
kubernetes component=apiserver,provider=kubernetes <no 
# 

# kubectl get pods 

NAME READY STATUS RESTARTS AGE 


让 我 们 检查 一 下 此 时 某 个 Node 上 的 网 络 接口 都 有 哪些 。Nodel 的 状 
态 是 : 
# ifconfig 
dockerO: flags=4099<UP, BROADCAST, RUNNING,MULTICAST> mtu 
inet 10.1.10.1 netmask 255.255.255.0 broadcast 
inet6 fe80::5484:7aff:fefe:9799 prefixlen 64 sı 
ether 56:84:7a:fe:97:99 txqueuelen 0 (Ethernet 
RX packets 373245 bytes 170175373 (162.2 MiB) 


RX errors © dropped © overruns © frame 0 


TX packets 353569 bytes 353948005 (337.5 MiB) 


TX errors © dropped © overruns © carrier © co 


eno16777736: flags=4163<UP, BROADCAST, RUNNING, MULTICAST> 
inet 192.168.1.129 netmask 255.255.255.0 broad 
inet6 fe80::20c:29ff:fe47:6e2c prefixlen 64 sc 
ether 00:0c:29:47:6e:2c txqueuelen 1000 (Ether 
RX packets 326552 bytes 286033393 (272.7 MiB) 
RX errors © dropped © overruns © frame 0 
TX packets 219520 bytes 31014871 (29.5 MiB) 


TX errors © dropped © overruns © carrier © co 


lo: flags=73<UP, LOOPBACK, RUNNING> mtu 65536 
inet 127.0.0.1 netmask 255.0.0.0 
inet6 ::1 prefixlen 128 scopeid 0x10<host> 
loop txqueuelen © (Local Loopback) 
RX packets 24095 bytes 2133648 (2.0 MiB) 
RX errors © dropped © overruns © frame 0 
TX packets 24095 bytes 2133648 (2.0 MiB) 


TX errors © dropped © overruns © carrier © co 


可 以 看 出 ， 有 一 个 docker0 网 桥 和 一 个 本 地 地 址 的 网 络 端口 。 现 在 
部 署 一 下 我 们 在 前 面 准备 的 RC/Pod 配 置 文件 ， 看 看 发 生 了 什么 : 





# kubectl create -f frontend-controller.yaml 
replicationcontrollers/frontend 


# 


# kubectl get pods 


NAME READY STATUS RESTARTS AGE 
frontend-4011g 1/1 Running 0 11s 1' 


可 以 看 到 一 些 有 趣 的 事情 。Kubernetes 为 这 个 Pod 找 了 一 个 主机 
192.168.1.130 (Node2) 来 运行 它 。 另 外 ， 这 个 Pod 还 获得 了 一 个 在 
Node2 的 docker0 网 桥 上 的 卫 地 址 。 我 们 登录 到 Node2 上 看 看 发 生 了 什么 
事情 : 


# docker ps 

CONTAINER ID IMAGE COMMAND CREATED 
37b193a4c633 kubeguide/example-guestbook-php-redis 
6dib99cff4ae google_containers/pause: latest "/pau 





在 Node2 上 现在 运行 了 两 个 容器 。 在 我 们 的 RC/Pod 定 义 文件 中 仅仅 
包含 了 一 个 ， 那 么 这 第 2 个 是 从 哪里 来 的 呢 ? 第 2 个 看 起 来 运行 的 是 一 个 
叫 作 google_containers/pause: latest 的 镜像 ， 而 且 这 个 容器 已 经 有 端口 映 
射 到 它 上 面 了 ， 为 什么 是 这 样 呢 ? 让 我 们 深入 容器 内 部 去 看 一 下 有 具体 原 
因 。 使 用 Docker 的 “inspect” 命 令 来 查看 容器 的 详细 信息 ， 特 别 要 关注 容 
器 的 网 络 模型 。 











# docker inspect 6d1b99cff4ae | grep NetworkMode 
"NetworkMode": "bridge", 
# docker inspect 37b193a4c633 | grep NetworkMode 


"NetworkMode": "container :6d1b99cff4ae537689ce87 





Aina Ree, ERA EENAA, RET AE Be 


样 的 配置 : 我们 检查 的 第 1 个 容器 是 运行 了 “google_containers/pause: 
latest” 镜 像 的 容器 ， 它 使 用 了 Docker 默 认 的 网 络 模型 bridge; 而 我 们 检查 
的 第 2 个 容器 ， 也 就 是 在 我 们 RC/Pod 中 定义 运行 的 php-redis 容 器 ， 使 用 
了 非 默 认 的 网 络 配 置 和 映射 容器 的 模型 ， 指 定 了 映射 目标 容器 


为 “google_containers/pause: latest”。 





我 们 一 起 来 仔细 思考 一 下 这 个 过 程 ， 为 什么 Kubernetes 要 这 么 做 
呢 ? 首 先 ， 一 个 Pod 内 的 所 有 容器 都 需要 共用 同一 个 IP 地 址 ， 这 就 意味 
着 一 定 要 使 用 网 络 的 容器 映射 模式 。 然 而 ， 为 什么 不 能 只 局 动 第 1 个 Pod 
中 的 容器 ， 而 将 第 2 个 Pod 内 的 容器 关联 到 第 1 个 容器 呢 ? 我 们 认为 
Kubernetes 从 两 个 方面 来 考虑 这 个 问题 : 首先 ， 如 果 Pod 有 超过 两 个 容器 
的 话 ， 则 连接 这 些 容器 可 能 不 容易 ， 其 次 ， 后 面 的 容器 还 要 依赖 第 1 个 
被 关联 的 容器 ， 如 果 第 2 个 容器 关联 到 第 1 个 容器 ， 且 第 1 个 容器 死 挥 的 
话 ， 第 2 个 也 将 死 控 。 启 动 一 个 基础 容器 ， 然 后 将 Pod 内 的 所 有 容器 都 连 
接 到 它 上 面 会 更 容易 一 些 。 因 为 我 们 只 需要 为 基础 的 这 个 
Google_containers/pause 容 器 执行 端口 映射 规则 ， 这 也 简化 了 端口 映射 的 
过 程 。 所 以 我 们 的 Pod 的 网 络 模型 类 似 于 图 3.32。 








php-redis 
80 端 口 转发 


pause 
10.1.20.4 





图 3.32 ”启动 Pod 后 网 络 模型 





在 这 种 情况 下 ， 实 际 Pod 的 JP 数据 流 的 网 络 目标 都 是 这 个 


google_containers/pause 容 器 。 图 3.32 有 点 儿 取 巧 地 显示 了 是 
google_containers/pause 容 器 将 端口 80 的 流量 转发 给 了 相关 的 容器 。 而 
Pause 只 是 逻辑 上 的 ， 并 没有 真 的 这 么 做 。 实 际 上 男 外 的 Web 容 器 直接 
监听 了 这 些 端口 ， 和 google_containers/pause 容 器 共享 了 同一 个 网 络 堆 
栈 。 这 就 是 为 什么 Pod 内 部 实际 容器 的 端口 映射 都 显示 到 
google_containers/pause 容 器 上 了。 我 们 可 以 通过 docker port 命 令 来 检验 
一 下 : 


# docker ps 

CONTAINER ID IMAGE 

37b193a4c633 kubeguide/example-guestbook-php-redi 
6d1b99cff4ae google_containers/pause:latest 

# 


# docker port 6d1b99cff4ae 
80/tcp ->0.0.0.0:80 








综 上 所 述 ，google_containers/pause 容 器 实际 上 只 是 负责 接管 这 个 
Pod 的 Endpoint， 它 实际 上 并 没有 做 更 多 的 事情 。 那 么 Node 呢 ， 它 需要 
将 数据 流传 给 google_containers/pause 容 器 吗 ? 我 们 来 检查 一 下 Iptables 的 
规则 ， 看 看 有 什么 发 现 : 


# iptables-save 

# Generated by iptables-save v1.4.21 on Thu Sep 24 17:15 
*nat 

:PREROUTING ACCEPT [0:0] 

: INPUT ACCEPT [0:0] 

: OUTPUT ACCEPT [0:0] 


:POSTROUTING ACCEPT [0:0] 

:DOCKER - [0:0] 

:KUBE-NODEPORT-CONTAINER - [0:0] 

:KUBE-NODEPORT-HOST - [0:0] 

:KUBE-PORTALS-CONTAINER - [0:0] 

:KUBE-PORTALS-HOST - [0:0] 

-A PREROUTING -m comment --comment "handle ClusterIPs; NI 
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER 

-A PREROUTING -m addrtype --dst-type LOCAL -m comment -- 
-A OUTPUT -m comment --comment "handle ClusterIPs; NOTE: 
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL 

-A OUTPUT -m addrtype --dst-type LOCAL -m comment --comm 
-A POSTROUTING -s 10.1.20.0/24 ! -o dockerO -j MASQUERAD 
-A KUBE-PORTALS-CONTAINER -d 20.1.0.1/32 -p tcp -m comme 
-A KUBE-PORTALS-HOST -d 20.1.0.1/32 -p tcp -m comment -- 
COMMIT 

# Completed on Thu Sep 24 17:15:01 2015 

# Generated by iptables-save v1.4.21 on Thu Sep 24 17:15 
*filter 

: INPUT ACCEPT [1131:377745] 

: FORWARD ACCEPT [0:0] 

: OUTPUT ACCEPT [1246:209888] 

:DOCKER - [0:0] 

-A FORWARD -o docker0 -j DOCKER 

-A FORWARD -o docker® -m conntrack --ctstate RELATED, EST, 
-A FORWARD -i dockerO ! -o docker0 -j ACCEPT 


-A FORWARD -i dockerO -o dockerO -j ACCEPT 


-A DOCKER -d 172.17.0.19/32 ! -i dockerO -o dockerg -pt 
COMMIT 
# Completed on Thu Sep 24 17:15:01 2015 


上 面 的 这 些 规 则 并 没有 应 用 到 我 们 刚刚 定义 的 Pod。 当 然 ， 
Kubernetes 会 给 每 一 个 Kubernetes 的 节点 提供 一 些 默认 的 服务 ， 上 面 的 规 
则 就 是 Kubernetes 的 默认 服务 需要 的 。 关 键 是 ， 我 们 没有 看 到 任何 IP 伪 
装 的 规则 ， 并 且 没 有 任何 指向 Pod 10.1.20.4 的 内 部 方向 的 端口 映射 。 


第 2 步 : 发 布 一 个 服务 


我 们 已 经 了 解 了 Kubermetes 如 何 处 理 最 基本 的 元 素 Pod 的 连接 问题 ， 
接 下 来 看 一 下 它 是 如 何 处 理 Service 的 。Service 人 允许 我 们 在 多 个 Pod 之 间 
抽象 一 些 服务 ， 而 且 ， 服 务 可 以 通过 提供 在 同一 个 Service 的 多 个 Pod 之 
间 的 负载 均衡 机 制 来 支持 水 平 扩 展 。 我 们 再 次 将 环境 初始 化 ， 删 除 刚 刚 
创建 的 RC/Pod 来 确保 集群 是 空 的 : 


# kubectl stop rc frontend 
replicationcontroller/frontend 

# 

# kubectl get rc 

CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLIC, 
# 

# kubectl get services 

NAME LABELS 

kubernetes component=apiserver, provider=kubernetes 

# 


# kubectl get pods 


NAME READY STATUS RESTARTS AGE 


然后 准备 一 个 名 称 为 frontend 的 Service 配 置 文件 ; 


apiversion: vi 
kind: Service 
metadata: 
name: frontend 
labels: 
name: frontend 
spec: 
ports: 
- port: 80 
# nodePort: 30001 
selector: 
name: frontend 
# type: 


# NodePort 


然后 在 Kubernetes 集 群 中 定义 这 个 服务 : 


# kubectl create -f frontend-service.yaml 
services/frontend 

# kubectl get services 

NAME LABELS SELECTOR 
frontend name=frontend name=frontend 


kubernetes component=apiserver, provider=kubernet: 


服务 正确 创建 后 ， 可 以 看 到 Kubernetes 集 群 已 经 为 这 个 服务 分 配 了 
一 个 虚拟 IP 地 址 20.1.244.75， 这 个 IP 地 址 是 在 Kubernetes 的 Portal 
Network 中 分 配 的。 而 这 个 Portal Network 的 地 址 范围 则 是 我 们 在 
Kubmaster 上 启动 API 服 务 进程 时 ， 使 用 --service-cluster-ip-range=xx 命 令 
行 参数 指定 的 : 


# cat /etc/kubernetes/apiserver 
# Address range to use for services 


KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=20.1.! 


这 个 IP 段 可 以 是 任何 段 ， 只 要 不 和 docker0 或 者 物理 网 络 的 子 网 冲突 
就 可 以 。 选 择 任意 其 他 网 段 的 原因 是 这 个 网 段 将 不 会 在 物理 网 络 和 
docker0 网 络 上 进行 路 由 。 这 个 Portal Network 针 对 每 一 个 Node 都 有 局 部 
的 特殊 性 ， 实 际 上 它 存在 的 意义 是 让 容器 的 流量 都 指 癌 默认 网 关 〈 也 就 
是 docker0 网 桥 ) 。 在 继续 实验 前 ， 先 登录 到 Node1 上 看 一 下 我 们 定义 服 
务 后 发 生 了 什么 变化 。 首 先 检查 一 下 Iptables/Netfilter 的 规则 : 





# iptables-save 
-A KUBE-PORTALS-CONTAINER -d 20.1.244.75/32 -p tcp -m col 
-A KUBE-PORTALS-HOST -d 20.1.244.75/32 -p tcp -m comment 


第 1 行 是 挂 在 PREROUTING 链 上 的 端口 重 定向 规则 ， 所 有 的 进 流量 
如 果 满 足 20.1.244.75: 80， 则 都 会 被 重 定向 到 端口 33761。 第 2 行 是 挂 在 


OUTPUT 链 上 的 目标 地 址 NAT， 做 了 和 上 述 第 1 行规 则 类 似 的 工作 ， 但 

针对 的 是 当前 主机 生成 的 外 出 流量 。 所 有 主机 生成 的 流量 都 需要 使 用 这 
个 DNAT 规 则 来 处 理 。 简 而 言 之 ， 这 两 个 规则 使 用 了 不 同 的 方式 做 了 类 
似 的 事情 ， 就 是 将 所 有 从 节点 生成 的 发 送 给 20.1.244.75: 80 的 流量 重 定 
向 到 本 地 的 33761 端 口 。 


到 此 为 止 ， 目 标 为 Service IP 地 址 和 端口 的 任何 流量 都 将 被 重 定 癌 到 
本 地 的 33761 端 口 。 这 个 端口 连 到 哪里 去 了 呢 ? 这 就 到 了 kube-proxy 发 挥 
作用 的 地 方 了 。 这 个 kube-proxy 服 务 给 每 一 个 新 创建 的 服务 关联 了 一 个 
随机 的 端口 号 ， 并 且 监 听 那 个 特定 的 端口 ， 为 服务 创建 相关 的 负载 均衡 
对 象 。 在 我 们 的 实验 中 ， 随 机 生成 的 端口 刚好 是 33761。 通 过 监控 Nodel 
上 的 Kubernetes-Service 的 日 志 ， 在 创建 服务 时 ， 我 们 可 以 看 到 下 面 的 记 
X: 





2612 proxier.go:413] Opened iptables from-containers por 


2612 proxier.go:424] Opened iptables from-host portal fo 


现在 我 们 知道 ， 所 有 的 流量 都 被 导入 kube-proxy。 现 在 我 们 需要 它 
完成 一 些 负载 均衡 的 工作 。 创 建 Replication Controller 并 观察 结果 ， 下 面 
是 Replication Controller 的 配置 文件 : 


apiVersion: v1 
kind: ReplicationController 
metadata: 

name: frontend 

labels: 


name: frontend 


spec: 
replicas: 3 
selector: 
name: frontend 
template: 
metadata: 
labels: 
name: frontend 
spec: 
containers: 
- name: php-redis 
image: kubeguide/example-guestbook-php-redis 
env: 
- name: GET_HOSTS_FROM 
value: env 
ports: 
- containerPort: 80 


# hostPort: 80 


在 集群 发 布 上 述 配置 文件 后 ， 等 竺 并 观察 ， 确 保 所 有 Pod 都 运行 起 
RI: 





# kubectl create -f frontend-controller.yaml 
replicationcontrollers/frontend 

# 

# kubectl get pods -o wide 


NAME READY STATUS RESTARTS AGE 


frontend-64t8q 1/1 Running 0 5s 
frontend-dzqve 1/1 Running © 5s 


frontend-x5dwy 1/1 Running © 5s 


现在 所 有 的 Pod 都 运行 起 来 了 ，Service 将 会 对 匹配 到 标签 
为 name=frontend” 的 所 有 Pod 进 行 负载 分 发 。 因 为 Service 的 选择 匹配 所 
有 的 这 些 Pod， 所 以 我 们 的 负载 均衡 将 会 对 这 3 个 Pod 进 行 分 发 。 现 在 我 
们 做 实验 的 环境 如 图 3.33 所 示 。 
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图 3.33 ”局 动 服务 后 的 结构 





Kubernetes 的 kube-proxy 看 起 来 只 是 一 个 夹层 ， 但 实际 上 它 只 是 在 
Node 上 运行 的 一 个 服务 。 上 述 重 定向 规则 的 结果 束 是 针对 目标 地 址 为 服 
务 IP 的 流量 ， 将 Kubernetes 的 kube-proxy 变 成 了 一 个 中 间 的 夹层 。 





为 了 但 看 具体 的 重 定 同 动作 ， 我 们 会 使 用 tcpdump 来 进行 网 络 抓 包 
操作 。 首 先 ， 安 装 tcpdump: 


yum-yinstall tcpdump 
安装 完成 后 ， 登 录 Node1， 运 行 ttpdump 命 令 : 
tcpdump -nn-q-ieno16777736 port80 


需要 捕获 物理 服务 器 以 太 网 接口 的 数据 包 ，Nodel 机 器 上 的 以 太 网 
接口 名 字 叫 作 eno16777736 。 


再 打开 第 1 个 窗口 运行 第 2 个 tcpdump 程 序 ， 不 过 我 们 需要 一 些 额 外 
的 信息 去 运行 它 ， 即 挂 接 在 docker0 桥 上 的 虚拟 网 卡 Veth 的 名 字 。 我 们 看 
到 只 有 一 个 frontend 容 器 在 Nodel 主 机 上 运行 ， 所 以 可 以 使 用 简单 的 “ip 
addr” 命 令 来 查看 唯一 的 “Veth” 网 络 接 口 : 


# ip addr 

1: lo: <LOOPBACK, UP, LOWER_UP> mtu 65536 qdisc noqueue sti 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:0 
inet 127.0.0.1/8 scope host lo 


valid_lft forever preferred_lft forever 


inet6 ::1/128 scope host 
valid_lft forever preferred_lft forever 
2: eno16777736: <BROADCAST, MULTICAST, UP, LOWER_UP> mtu 15! 
link/ether 00:0c:29:47:6e:2c brd ff: ff: ff: ff: fF: ff 
inet 192.168.1.129/24 brd 192.168.1.255 scope global 
valid_lft forever preferred_lft forever 
inet6 fe80::20c:29ff:fe47:6e2c/64 scope link 
valid_lft forever preferred_lft forever 
3: docker0: <NO-CARRIER, BROADCAST, MULTICAST, UP> mtu 1500 
link/ether 56:84:7a:fe:97:99 brd ff: ff: ff: ff: ff: fF 
inet 10.1.10.1/24 brd 10.1.10.255 scope global docke 
valid_lft forever preferred_lft forever 
inet6 fe80: :5484: 7aff:fefe:9799/64 scope link 
valid_lft forever preferred_lft forever 
12: vethO558bfa: <BROADCAST,MULTICAST, UP, LOWER_UP> mtu 1! 
link/ether 86:82:e5:c8:5a:9a brd ff: ff: ff: ff: fF: ff 
inet6 fe80: :8482:e5ff:fec8:5a9a/64 scope link 


valid_lft forever preferred_lft forever 





复制 这 个 接口 的 名 字 ， 在 第 2 个 窗口 中 运行 tcpdump 命 令 。 


tcpdump -nn -q -i vetho558bfa host 20.1.244.75 





同时 运行 这 两 个 命令 ， 并 且 将 窗口 并 排放 置 ， 以 便 同 时 看 到 两 个 窗 
口 的 输出 : 


# tcpdump -nn -q -i eno16777736 port 80 


tcpdump: verbose output suppressed, use -v or -vv for fu. 


listening on eno16777736, link-type EN10MB (Ethernet), c 


# tcpdump -nn -q -i vethO558bfa host 20.1.244.75 
tcpdump: verbose output suppressed, use -v or -vv for fu. 


listening on vethO558bfa, link-type EN10MB (Ethernet), c 


好 了 ， 我 们 已 经 在 同时 捕获 两 个 接口 的 网 络 包 了 。 这 时 再 局 动 第 3 
个 窗口 ， 运 行 一 个 “docker exec” 命 令 来 连接 到 我 们 的 “frontend” 的 容器 内 
部 (你 可 以 先 执行 docker ps 来 获得 这 个 容器 的 ID : 


# docker ps 

CONTAINER ID IMAGE 

268ccdfb9524 kubeguide/example -guestbook-php-redi 
6a519772b27e google_containers/pause: latest 


执行 命令 进入 容器 内 部 : 


#docker exec -it 268ccdfb9524 bash 
# docker exec -it 268ccdfb9524 bash 


root@frontend-x5dwy:/# 


一 旦 进入 运行 的 容器 内 部 ， 我 们 就 可 以 通过 Pod 的 IP 地 址 来 访问 服 
务 了 。 使 用 curl 来 尝试 访问 服务 : 


curl20.1.244.75 


在 使 用 cu 访问 服务 时 ， 将 在 抓 包 的 两 个 窗口 内 看 到 : 
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第 2 个 窗口 中 网 络 抓 包 信息 


3.34 所 示 。 
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IP 


IP 


192.168.1.129.57452 >10.1.30.8.8080: 
10.1.30.8.8080 > 192.168.1.129.57452: 
192.168.1.129.57452 >10.1.30.8.8080: 
10.1.30.8.8080 > 192.168.1.129.57452: 


10.1.10.5.35225 > 20.1.244.75.80: tcp 
20.1.244.75.80 >10.1.10.5.35225: tcp | 
10.1.10.5.35225 > 20.1.244.75.80: tcp 
20.1.244.75.80 >10.1.10.5.35225: tcp | 


这 些 信 息 说 明了 什么 问题 呢 ? 让 我 们 在 网 络 图 上 用 实 线 标 出 第 1 个 


窗口 中 网 络 抓 包 信息 的 含义 〔 物 理 网 卡 上 的 网 络 流 量 ) ， 并 用 虚线 标 出 


的 含义 (docker0 网 桥 上 的 网 络 流量 ) ， 如 图 
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图 3.34 ”数据 流动 情况 图 1 


注意 ， 图 3.34 中 ， 虚 线 绕 过 了 Node3 的 kube-proxy， 这 么 做 是 因为 
Node3 上 的 kube-proxy 没 有 参与 这 次 网 络 交 互 。 换 名 话说，Nodel 的 
kube-proxy 服 务 直 接 和 负载 均衡 到 的 Pod 进 行 网 络 交 互 。 


在 查看 第 2 个 捕获 包 的 窗口 时 ， 我 们 能 够 站 在 容器 的 视角 看 这 些 流 
量 。 首 先 ， 容 器 尝试 使 用 20.1.244.75: 80 打 开 TCP 的 Socket 连 接 。 同 
时 ， 我 们 还 可 以 看 到 从 服务 地 址 20.1.244.75 返 回 的 数据 。 从 容器 的 视角 
来 看 ， 整 个 交互 过 程 都 是 在 服务 之 间 进 行 的 。 但 是 在 查看 一 个 捕获 包 的 
窗口 时 《上面 的 窗口 )， 我 们 可 以 看 到 物理 机 之 间 的 数据 交互 ， 可 以 看 





到 一 个 TCP 连 接 从 Nodel 的 物理 地 址 (192.168.1.129) 发 出 ， 直 接连 接 
到 运行 Pod 的 主机 Node3 (192.168.1.131) 。 总 而 言 之 ，Kubernetes 的 

kube-proxy 作 为 一 个 全 功能 的 代理 服务 器 管理 了 两 个 独立 的 TCP 连 接 : 
一 个 是 从 容 右 到 kube-proxy: 另 一 个 是 从 kube-proxy 到 负载 均衡 的 目标 


Pod 。 





如 果 我 们 清理 一 下 捕获 的 记录 ， 再 次 运行 curl， 则 还 可 以 看 到 网 络 
流量 被 负载 均衡 转发 到 另 一 个 节点 Node2 上 了 。 
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192.168.1.129.57485 >10.1.20.6.8080: ` 


10.1.20.6.8080 > 192.168.1.129.57485: 


192.168.1.129.57485 >10.1.20.6.8080: ` 


10.1.20.6.8080 > 192.168.1.129.57485: 


10.1.10.5.38026> 20.1.244.75.80: 
20.1.244.75.80 >10.1.10.5.38026: 
10.1.10.5.38026> 20.1.244.75.80: 
20.1.244,.75.80 >10.1.10.5.38026: 


tcp 
tcp 
tcp 
tcp 


这 一 次 ，Kubernetes 的 Proxy 将 选择 运行 在 Node2 (10.1.20.1) 上 面 
的 Pod 作 为 负载 均衡 的 目的 。 网 络 流动 图 如 图 3.35 所 示 。 


吧 。 
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图 3.35 ”数据 流动 情况 图 2 





到 这 里 ， 你 肯定 已 经 知道 男 外 一 个 可 能 的 负载 均衡 的 路 由 结果 了 


第 4 瘟 ”Kubernetes 开 发 指南 


本 章 将 引入 REST 的 概念 ， 详 细 说 明 Kubernetes API， 并 举例 说 明 如 
何 基于 Jersey 和 Fabric8 框 架 访 问 Kubernetes API， 深 入 分 析 基 于 这 两 个 框 
架 访 问 Kubernetes API 的 优 缺 点 。 下 面 从 REST 开 始 说 起 。 





41 REST 简 述 


REST (Representational State Transfer) 是 由 Roy Thomas Fielding 博 
士 在 他 的 论文 Architectural Styles and the Design of Network-based 
Software Architectures 中 提出 的 一 个 术语 。REST 本 身 只 是 为 分 布 式 超 媒 
体系 统 设 计 的 一 种 架构 风格 ， 而 不 是 标准 。 


基于 Web 的 架构 实际 上 就 是 各 种 规范 的 集合 ， 这 些 规范 共同 组 成 了 
Web 架 构 ， 比 如 HTTP、 客 户 端 服务 占 模 式 部 是 规范 。 每 当 我 们 在 原 有 
规范 的 基础 上 增加 新 的 规范 时 ， 束 会 形成 新 的 架构 。 而 REST 正 是 这 样 
一 种 架构 ， 它 结合 了 一 系列 规范 ， 形 成 了 一 种 新 的 基于 Web 的 架构 风 
格 。 


传统 的 Web 应 用 大 多 是 B/S 架构 ， 涉 及 如 下 规范 。 


(1) SPR ae: 这 种 规范 的 提出 ， 改 善 了 用 户 接 口 跨 多 个 平台 
的 可 移植 性 ， 并 且 通 过 简化 服务 器 组 件 ， 改 善 了 系统 的 可 伸缩 性 。 最 为 
关键 的 是 通过 分 离 用 户 接口 和 数据 存储 ， 使 得 不 同 的 用 己 终 端 共 吾 相 反 
的 数据 成 为 可 能 。 


可 





(2) 无 状态 性 : 无 状态 性 是 在 客户 -服务 器 约束 的 基础 上 添加 的 又 
一 层 规范 ， 它 要 求 通信 必须 在 本 质 上 是 无 状态 的 ， 即 从 客户 端 到 服务 器 
的 每 个 request 都 必须 包含 理解 该 request 所 必需 的 所 有 信息 。 这 个 规范 改 
善 了 系统 的 可 见 性 《无 状态 性 使 得 客户 端 和 服务 器 端 不 必 保 存 对 方 的 详 
细 人 信息， 服务器 只 需要 处 理 当 前 的 request， 而 不 必 了 解 所 有 request 的 历 
史 ) 、 可 靠 性 〈 无 状态 性 减少 了 服务 器 从 局 部 错误 中 恢复 的 任务 量 ) 、 





可 伸缩 性 〈 无 状态 性 使 得 服务 器 端 可 以 很 容易 地 释放 资源 ， 因 为 服务 丹 
端 不 必 在 多 个 request 中 保存 状态 ) 。 同 时 ， 这 种 规范 的 缺点 也 是 显 而 易 
见 的 ， 由 于 不 能 将 状态 数据 保存 在 服务 右上， 因此 增加 了 在 一 系列 
request 中 发 送 重 复数 据 的 开销 ， 严 重 降 低 了 效率 。 








(3) Bee: 为 了 改善 无 状态 性 市 来 的 网 络 的 低 效 性 ， 我 们 添加 了 
绥 存 约束 。 绥 存 约束 允许 隐 式 或 显 式 地 标记 一 个 response 中 的 数据 ， 赋 
予 了 客户 端 缓 存 response 数 据 的 功能 ， 这 样 束 可 以 为 以 后 的 request 共 用 
绥 存 的 数据 ， 部 分 或 全 部 地 消除 一 部 分 交互 ， 提 高 了 网 络 效率 。 但 是 由 
于 客户 端 缓存 了 信息 ， 所 以 增加 了 客户 并 与 服务 器 数据 不 一 致 的 可 能 
性 ， 从 而 降低 了 可 靠 性 。 











B/S 架 构 的 优点 是 部 署 非常 方便 ， 在 用 户 体验 方面 却 不 很 理想 。 为 
了 改善 这 种 情况 ， 我 们 引入 了 REST。REST 在 原 有 架构 上 增加 了 三 个 新 
规范 : 统一 接口 、 分 层 系统 和 按 需 代码 。 


(1) 统一 接口 : REST 架 构 风 格 的 核心 特征 就 是 强调 组 件 之 间 有 一 
个 统一 的 接口 ， 表 现 为 在 REST 世 界 里 ， 网 络 上 的 所 有 事物 都 被 抽象 为 
资源 ，REST 通 过 通用 的 链接 器 接口 对 资源 进行 操作 。 这 样 设计 的 好 处 
是 保证 系统 提供 的 服务 都 是 解 耦 的 ， 极 大 地 简化 了 系统 ， 从 而 改善 了 系 
统 的 交互 性 和 可 重用 性 。 


D 分 层 系统 : 分 层 系 统 规则 的 加 入 提高 了 各 种 层次 之 间 的 独立 
性 ， 为 整个 系统 的 复杂 性 设置 了 边界 ， 通 过 封装 遗留 的 服务 ， 使 新 的 服 
务 需 免 受 遗留 客户 端的 影响 ， 也 提高 了 系统 的 可 伸缩 性 。 


(3) 按 需 代码 : REST 人 允许 对 客户 并 功能 进行 扩展 。 比 如 ， 通 过 下 
载 并 执行 applet 或 脚本 形式 的 代码 来 扩展 客户 端的 功能 。 但 这 在 改善 系 


统 可 扩展 性 的 同时 降低 了 可 见 性 ， 所 以 它 只 是 REST 的 一 个 可 选 约束 。 


REST 染 构 是 针对 Web 应 用 而 设计 的 ， 其 目的 是 为 了 降低 开发 的 复 
杂 性 ， 提 高 系统 的 可 伸缩 性 。REST 提 出 了 如 下 设计 准则 。 


(1) 网 络 上 的 所 有 事物 都 被 抽象 为 资源 (Resource) 。 
(2) 每 个 资源 对 应 一 个 唯一 的 资源 标识 符 (Resource Identifier) 。 


(3) 通过 通用 的 连接 器 接口 (Generic Connector Interface) 对 资源 
进行 操作 。 


C4) 对 资源 的 各 种 操作 不 会 改变 资源 标识 和 从。 
(5) 所 有 的 操作 都 是 无 状态 的 (Stateless)。 





REST 中 的 资源 所 指 的 不 是 数据 ， 而 是 数据 和 表现 形式 的 组 合 ， 比 
如 “最 新 访问 的 10 位 会 员 ” 和 “最 活跃 的 10 位 会 员 ” 在 数据 上 可 能 有 重 半 或 
者 完全 相同 ， 而 由 于 它们 的 表现 形式 不 同 ， 所 以 被 归 为 不 同 的 资源 ， 这 
也 就 是 为 什么 REST 的 全 名 是 Representational State Transfer。 资 源 标识 符 
就 是 URI (Uniform Resource Identifier) ， 不 管 是 图 片 、Word 还 是 视频 
文件 ， 甚 至 只 是 一 种 虚拟 的 服务 ， 也 不 管 是 xml、txt 还 是 其 他 文件 格 
式 ， 全 部 通过 URI 对 资源 进行 唯一 标识 。 





REST 是 基于 HTTP 的 ， 任 何 对 资源 的 操作 行为 都 通过 HTTP 来 实 
现 。 以 往 的 Web 开 发 大 多 数 用 的 是 HTTP 中 的 GET 和 POST 方 法 ， 很 少 使 
用 其 他 方法 ， 这 实际 上 是 因为 对 HITP 的 片面 理解 造成 的 。HTTP 不 仅仅 
是 一 个 简单 的 运载 数据 的 协议 ， 而 且 是 一 个 具有 丰富 内 涵 的 网 络 软件 的 
协议 ， 它 不 仅 能 对 互联 网 资源 进行 唯一 定位 ， 还 能 告诉 我 们 如 何 对 该 资 
源 进行 操作 。HTTP 把 对 一 个 资源 的 操作 限制 在 4 种 方法 内 : GET、 





POST、PUT 和 DELETE， 这 正 是 对 资源 CRUD 操 作 的 实现 。 由 于 资源 和 
URI 是 一 一 对 应 的 ， 在 执行 这 些 操 作 时 URI 没 有 变化 ， 和 以 往 的 Web 开 
发 有 很 大 的 区 别 ， 所 以 极 大 地 简化 了 Web 开 发 ， 也 使 得 URI 可 以 被 设计 
成 更 为 直观 地 反映 资源 的 结构 。 这 种 URI 的 设计 被 称 作 RESTful 的 URI， 
为 开发 人 员 引 入 了 一 种 新 的 思维 方式 : 通过 URL 来 设计 系统 结构 。 当 然 
了 ， 这 种 设计 方式 对 于 一 些 特定 情况 也 是 不 适用 的 ， 也 就 是 说 不 是 所 有 
URI 都 适用 于 RESTful。 


REST 之 所 以 可 以 提高 系统 的 可 伸缩 性 ， 就 是 因为 它 要 求 所 有 操作 
都 是 无 状态 的 。 由 于 没有 了 上 下 文 (Context〉 的 约束 ， 做 分 布 式 和 集群 
时 就 更 为 简单 ， 也 可 以 让 系统 更 为 有 效 地 利用 缓冲 池 〈Pool) ， 并 且 由 
于 服务 器 端 不 需要 记录 客户 问 的 一 系列 访问 ， 也 就 减少 了 服务 器 端的 性 
能 损耗 。 





Kubernetes API 也 符合 RESTful 规 范 ， 下 面 对 其 进行 介绍 。 


4.2 Kubernetes API 详 解 


4.2.1 Kubernetes API 概 述 


Kubernetes API 是 集群 系统 中 的 重要 组 成 部 分 ，Kubernetes 中 各 种 资 
源 OF RO 的 数据 通过 该 API 接 口 被 提交 到 后 端的 持久 化 存储 〈etcd ) 
中 ，Kubernetes 集 群 中 的 各 部 件 之 间 通 过 该 API 接 口 实现 解 厢 合 ， 同 时 
Kubernetes 集 群 中 一 个 重要 且 便 捷 的 管理 工具 kubectl 也 是 通过 访问 该 API 
接口 实现 其 强大 的 管理 功能 的 。Kubernetes API 中 的 资源 对 象 都 拥有 通 
用 的 元 数据 ， 资 源 对 象 也 可 能 存在 伦 套 现象 ， 比 如 在 一 个 Pod 里 面 诅 套 
多 个 Container。 创 建 一 个 API 对 象 是 指 通过 API 调 用 创建 一 条 有 意义 的 记 
录 ， 该 记录 一 旦 被 创建 ，Kubernetes 将 确保 对 应 的 资源 对 象 会 被 自动 创 
建 并 托管 维护 。 





在 Kubernetes 系 统 中 ， 大 多 数 情况 下 ，API 定 义 和 实 现 都 符合 标准 的 
HTTP REST 格 式 ， 比 如 通过 标准 的 HTTP 动 词 (POST. PUT. GET. 
DELETE) 来 完成 对 相关 资源 对 象 的 查询 、 创 建 、 修 改 、 删 除 等 操作 。 
但 同时 Kubernetes 也 为 某 些 非 标准 的 REST 行 为 实现 了 附加 的 API 接 口 ， 
例如 Watch 某 个 资源 的 变化 、 进 入 容器 执行 某 个 操作 等 。 另 外 ， 某 些 
API 接 口 可 能 违背 严格 的 REST 模 式 ， 因 为 接口 不 是 返回 单一 的 JSON 对 
象 ， 而 是 返回 其 他 类 型 的 数据 ， 比 如 JSON 对 象 流 (Stream) 或 非 结构 
化 的 文本 日 志 数据 等 。 








Kubernetes 开 发 人 员 认 为 ， 任 何 成 功 的 系统 都 会 经 历 一 个 不 断 成 长 


和 不 断 适 应 各 种 变更 的 过 程 。 因 此 ， 他 们 期 望 Kubernetes API 是 不 断 变 
更 和 增长 的 。 同 时 ， 他 们 在 设计 和 开发 时 ， 有 意识 地 兼容 了 已 存在 的 客 
户 需 求 。 通 常 ， 新 的 API 资 源 CResource) 和 新 的 资源 域 不 希望 被 频繁 
地 加 入 系统 。 资 源 或 域 的 删除 需要 一 个 严格 的 审核 流程 。 








为 了 方便 查阅 API 接 口 的 详细 定义 ，Kubernetes 使 用 了 swagger-ui 提 
供 API 在 线 查 询 功 能 ， 其 官网 为 http://kubernetes.io/third_party/swagger- 
ui/，Kubernetes 开 发 团队 会 定期 更 新 、 生 成 UI 及 文档 。Swagger UI 是 一 
蒜 RESTAPI 文 档 在 线 自 动 生 成 和 功能 测试 软件 ， 关 于 Swagger 的 内 容 请 
访问 官网 http://swagger.io。 





运行 在 Master 节 点 上 的 API Server 进 程 同 时 提供 了 swagger-ui 的 访问 
地 址 : http://<master-ip>: <master-port>/swagger-ui/。 假 设 我 们 的 API 
Server 安 装 在 192.168.1.128 服 务 器 上 ， 绑 定 了 8080 端 口 ， 则 可 以 通过 访 
问 http://192.168.1.128: 8080/swagger-uj/ 来 查看 API 信 息 ， 如 图 4.1 所 示 。 





/ @ Swagger UI x b 
€ > C [[ kubemetesio/third_party/swagger-ui/#/ amy E 

















t} swagger http/kubemetes .io/third_party/swagger-ui/ /. /swagger-spec api_ke 


api : get available API versions Show/Hide | List Operations Expand Operations 
api/v1 : API at /api/v1 version v1 Show/Hide | List Operations | Expand Operations 
version : git code version from which this is built Show/Hide | List Operations | Expand Operations 
[ Base uri: /] B 











图 4.1 swagger-ui 


单 击 api/v1 可 以 查看 所 有 API 的 列表 ， 如 图 4.2 所 示 。 


|j ® Swagger UI *\ = 





e > C [D kubernetesio/third_party/swagger-ui/#/ 





{) Swagger http //kubemetes ioithird_party/swagger-uil / /swagger-spec Explore 





api : get available API versions Show/Hide List Operations | Expand Operations 
api/v1 : API at /api/v1 version v1 Show/Hide List Operations ` Expand Operations 
Ea /api/v1 /namespaces/{namespace}/bindings create a Binding 
Eq Japi/v1/bindings create a Binding 
Ea /api/v1 /namespaces/{namespace}/componentstatuses list objects of kind ComponentStatus 
Ea /api/v1 /namespaces/{namespace}/componentstatuses/{name} read the specified ComponentStatus 
Ea Japi/v1/componentstatuses list objects of kind ComponentStatus 
EEJ 2011 namespaces/inamespacey/endpoints list or watch objects of kind Endpoints 
Japi/v1/namespaces/{namespace}/endpoints create a Endpoints 
Ea /api/v1/watch/namespaces/{namespace}/endpoints watch individual changes to a list of Endpoints 
EE 2pivvinamespaces/{namespace}/endpoints/{name} delete a Endpoints 





图 4.2 ”查看 API 列 表 


以 create a Pod 为 例 ， 找 到 Rest API 的 访问 路 径 
JJ: /api/vl/namespaces/{namespace}pods， 如 图 4.3 所 示 。 


| ros | /api/v1/namespaces/{namespace}/pods create a Pod 


图 4.3 Create a Pod API 


单 击 链接 展开 ， 即 可 查看 详细 的 API 接 口 说 明 ， 如 图 4.4 所 示 。 














Parameters 
Parameter Value Description Lacie Data Type 
pretty (empty) If tue’, then the query string 
output is pretty 
body required) body 











图 4.4 Create a Pod API 详 细 说 明 


单 击 Model 链 接 ， 则 可 以 查看 文本 格式 显示 的 API 接 口 描 述 ， 如 图 
4.5 所 示 。 





















































































= o x 
® Swagger U! x 
所 CD kubemetes.io/third_party/swagger-ui/#!/apise2Fv 1 /createNamespacedPod Q fa sr) = 
Ea /api/v1/namespaces/{namespace}/pods ui 
Response Class (Status 200) 
a v1.pod{ 
kind (string, o a): kind of object. in CamelCase; cannot be updated; see http://release: pi-conventions. md#types-kinds. 
apiVersion (s lon of the schema the object should have; see http:// ons.md#resources, 
metadata (v1 tional, 
spec (v1.P. 
status (v1 Poc , optional 
} 
v1.ObjectMeta { 
name (string. optiona: s t identifies an object. Must be unique within a namespace; cannot be updated; see 
htto://release: d#names 
generateName ( al prefix to use to generate a unique name; has the same validation rules as name; optional, and is applied only 
name If is not ied; see http:/ 
namespace ( al: namespac tip ://releases.k8s.io/HEAD/docs/namespaces.md, 
selfLink (string, optiona): URL for the object; populated by the system, read-only, 
uid (string, optiona): unique UUID across space and time; populated by the system; read-only; see bttp-//releases k&s io/HEAD/docs/identifiers md#uids, 
resourceVersion (string, optional): string that identifies the internal version of this object that can be used by clients to determine when objects have changed; 
populated by the sys nly; value must be treated as opaque by clients and passed unmodified back to the server 
http://release. ntions.md#concurre ntr c 
generation (inte. tional: a sequence number repre: state; popula: the system; read-only, 
creationTimestamp (string, 0; 小 RFC 3339 date and time at which the object was cre ulated by the m, read-only; null for lists; see 
hup//rele Bs io/HE a 
deletionTimestamp (string, optional: R at which the object will be deleted; populated by the system when a graceful deletion is 
requested, read-only; if not set, graceful deletion of the object has not been requested; see http’//releases k8s jo/HEAD/docs/api-conventions md#metadat 
labels (undefined, optional, 
annotations (undefined, optional, 
} 
v1.Podspec { 
1 optional: list of volumes that can be mounted by containers belonging to the pod; see 
containers (Array[v J}: list of contain le pod; cannot be updated; containers cannot currently be added or removed; there must be 
at least one container in a Pod; see http-//re ontainers.md, 
restartPolicy (string, optiona): restart policy for all containers within the pad; one of Always, OnFailure, Never; defaults to Always, see 
http://releases kBs io/HEAD/docs/pod-st estartpolicy, 
terminationGracePeriodSeconds (i optional duration in seconds the pod needs to terminate gracefully: may be decrea 
value must be non-negative integ dicates delete immediately: if this value is n the default gr riod will bi 
period Is the duration in secon running in the pod are sent a termination signal and the time when the pr = 





图 4.5 Create a Pod API 文 本 格式 详细 说 明 


我 们 看 到 ， 在 Kubernetes API 中 ， 一 个 API 的 顶层 (Top Level) 元 素 
由 kind、apiVersion、metadata、spec 和 status 等 几 个 部 分 组 成 ， 接 下 来 ， 
我 们 分 别 对 这 几 个 部 分 进行 说 明 。 





kind 表 明 对 象 有 以 下 三 大 类 别 。 


(1) 对 象 Cobjects) : 代表 在 系统 中 的 一 个 永久 资源 (实体 ) ， 
例如 Pod、RC、Service、Namespace 及 Node 等 。 通 过 操作 这 些 资 源 的 属 
性 ， 客 户 端 可 以 对 该 对 象 进行 创建 、 修 改 、 删 除 和 获取 操作 。 


(2) 列表 Gist) : 一 个 或 多 个 资源 类 别 的 集合 。 列 表 有 一 个 通用 
元 数据 的 有 限 集合 。 所 有 列表 (ists〉 通 过 “items” 域 获得 对 象 数组 ， 例 
如 PodLists、ServiceLists、NodeLists。 大 部 分 定义 在 系统 中 的 对 象 都 有 
一 个 返回 所 有 资源 (resource) 集合 的 端点 ， 以 及 零 到 多 个 返回 所 有 资 





源 集合 的 子 集 的 端点 。 某 些 对 象 有 可 能 是 单 例 对 象 〈singletons) ， 例 如 
当前 用 户 、 系 统 默认 用 户 等 ， 这 些 对 象 没有 列表 。 


(3) 简单 类 别 〈simple) : 该 类 别 包 含 作 用 在 对 象 上 的 特殊 行为 和 
非 持久 实体 。 该 类 别 限 制 了 使 用 范围 ， 它 有 一 个 通用 元 数据 的 有 限 集 
合 ， 例 如 Binding、Status 。 


apiVersion 表 明 API 的 版 本 号 ， 当 前 版 本 默认 只 文 持 v1。 


Metadata 是 资源 对 象 的 元 数据 定义 ， 是 集合 类 的 元 素 类 型 ， 包 含 一 
组 由 不 同名 称 定义 的 属性 。 在 Kubernetes 中 每 个 资源 对 象 都 必须 包含 以 
下 3 种 Metadata。 


(1) namespace: 对 象 所 属 的 命名 空间 ， 如 果 不 指定 ， 系 统 则 会 将 
对 象 置 于 名 为 “default” 的 系统 命名 空间 中 。 





(2) name: 对 象 的 名 字 ， 在 一 个 命名 空间 中 名 字 应 具备 唯一 性 。 

(3) uid: 系统 为 每 个 对 象 生 成 的 唯一 ID， 符 合 RFC 4122 规 范 的 定 
Se 

此 外 ， 每 种 对 象 还 应 该 包含 以 下 几 个 重要 元 数据 。 

(1) labels: 用 户 可 定义 的 “标签 ”， 键 和 值 都 为 字符 串 的 map， 是 


对 象 进行 组 织 和 分 类 的 一 种 手段 ， 通 常用 于 标签 选择 右 (Label 
Selector) ， 用 来 匹配 目标 对 象 。 


(2) annotations: 用 户 可 定义 的 “注解 ”>， 键 和 值 都 为 字符 串 的 
map， 被 Kubernetes 内 部 进程 或 者 某 些 外 部 工具 使 用 ， 用 于 存储 和 获取 
关于 该 对 象 的 特定 元 数据 。 


(3) resourceVersion: 用 于 识别 该 资源 内 部 版 本 号 的 字符 串 ， 在 用 
于 Watch 操作 时 ， 可 以 避免 在 GET 操 作 和 下 一 次 watch 操 作 之 间 造 成 的 信 
恩 不 一 致 ， 客 户 端 可 以 用 它 来 判断 资源 是 否 改变 。 该 值 应 该 被 客户 端 看 
作 不 透明 ， 且 不 做 任何 修改 就 返回 给 服务 端 。 客 户 端 不 应 该 假定 版 本 信 
号 具有 跨 命 名 空间 、 跨 不 同 资源 类 别 、 跨 不 同 服务 器 的 含义 。 





(4) creationTimestamp: 系统 记录 创建 对 象 时 的 时 间 惟 ， 符 合 RFC 
3339 规 范 。 


(5) deletionTimestamp: 系统 记录 删除 对 象 时 的 时 间 惟 ， 符 合 RFC 
3339 规 范 。 


(6) selfLink: 通过 API 访 问 资源 目 号 的 URL， 例 如 一 个 Pod 的 link 
可 能 是 /api/vl/namespaces/default/pods/frontend-08bg4。 


spec 是 集合 类 的 元 素 类 型 ， 用 户 对 需要 管理 的 对 象 进行 详细 描述 的 
主体 部 分 都 在 spec 里 给 出 ， 它 会 被 Kubernetes 持 久 化 到 etcd 中 保存 ， 系 统 
通过 spec 的 描述 来 创建 或 更 新 对 象 ， 以 达到 用 户 期 望 的 对 象 运 行 状态 。 
spec 的 内 容 既 包括 用 户 提供 的 配置 设置 、 默 认 值 、 属 性 的 初始 化 值 ， 也 
包括 在 对 象 创 建 过 程 中 由 其 他 相关 组 件 〈 例 如 schedulers、auto-scalers ) 
创建 或 修改 的 对 象 属性 ， 比 如 Pod 的 Service 了 IP 地 址 。 如 果 spec 被 删除 ， 
那么 该 对 象 将 会 从 系统 中 被 删除 。 








Status 用 于 记录 对 象 在 系统 中 的 当前 状态 信息 ， 它 也 是 集合 类 元 素 
类 型 ，status 在 一 个 自动 处 理 的 进程 中 被 持久 化 ， 可 以 在 流转 的 过 程 中 
生成 。 如 果 观 察 到 一 个 资源 丢失 了 它 的 状态 《〈Status) ， 则 该 丢失 的 状 
态 可 能 被 重新 构造 。 以 Pod 为 例 ，Pod 的 status 信 息 主 要 包括 conditions、 
containerStatuses、hostIP、phase、podIP、startTime 等 。 其 中 比较 重要 的 


两 个 状态 属性 如 下 。 


(1) phase: 描述 对 象 所 处 的 生命 周期 阶段 ，phase 的 典型 值 
是 “Pending (创建 中 ) ”“Running”“Active (正在 运行 
H) ”或 “Terminated (已 终结 ) ”， 这 几 种 状态 对 于 不 同 的 对 象 可 能 有 轻 
微 的 差别 ， 此 外 ， 关 于 当前 phase 附 加 的 详细 说 明 可 能 包含 在 其 他 域 
中 。 


(2) condition: 表示 条 件 ， 由 条 件 类 型 和 状态 值 组 成 ， 目 前 仪 有 
一 种 条 件 类 型 Ready， 对 应 的 状态 值 可 以 为 True、False 或 Unknown。 一 
个 对 象 可 以 具备 多 种 condition， 而 condition 的 状态 值 也 可 能 不 断 发 生变 
化 ，condition 可 能 附带 一 些 信 息 ， 例 如 最 后 的 探测 时 间或 最 后 的 转变 时 
间 。 


4.2.2 ”API 版 本 


为 了 在 兼容 旧版 本 的 同时 不 断 升 级 新 的 API，Kubernetes 提 供 了 多 版 
本 API 的 支持 能 力 ， 每 个 版 本 的 API 通 过 一 个 版 本 号 路 径 前 级 进行 区 
分 ， 例 如 /api/vlbeta3。 通 第 情况 下 ， 新 旧 几 个 不 同 的 API 版 本 都 能 涵 瘟 
所 有 的 Kubernetes 资 源 对 象 ， 在 不 同 的 版 本 之 间 这 些 API 接 口 存在 一 些 细 
微 差别 。Kubernetes 开 发 团队 基于 API 级 别 选 择 版 本 而 不 是 基于 资源 和 域 
级 别 ， 是 为 了 确保 API 能 够 描述 一 个 清晰 的 连续 的 系统 资源 和 行为 的 视 
图 ， 能 够 控制 访问 的 整个 过 程 和 控制 实验 性 API 的 访问 。 





API 及 版 本 发 布 建 议 描 述 了 版 本 升级 的 当前 思路 。 版 本 vlbetal、 
vlbeta2 和 v1lbeta3 为 不 建议 使 用 (Deprecated) 的 版 本 ,请 尽快 转 到 v1 版 
本 。 在 2015 年 6 月 4 日 ，Kubernetes v1 版 本 API 正 式 发 布 。 版 本 vlbetal 和 
vlbeta2API 在 2015 年 6 月 1 日 被 删除 ， 版 本 vlbeta3API 在 2015 年 7 月 6 日 被 
删除 。 


4.2.3 ”API 详细 说 明 


API 资 源 使 用 REST 模 式 ， 有 具体 说 明 如 下 。 


(1) GET/< 资 源 名 的 复数 格式 >: 获得 某 一 类 型 的 资源 列表 ， 例 如 
GETpods 返 回 一 个 Pod 资 源 列 表 。 


(2) POST/< 资 源 名 的 复数 格式 >: 创建 一 个 资源 ， 该 资源 来 自用 
户 提供 的 JSON 对 象 。 


(3) GET/< 资 源 名 复数 格式 >/< 名 字 >: 通过 给 出 的 名 称 (Name) 
获得 单个 资源 ， 例 如 GET/pods/first 返 回 一 个 名 称 为 “first” 的 Pod。 


(4) DELETE/< 资 源 名 复数 格式 >/< 名 字 >: 通过 给 出 的 名 字 删 除 单 
个 资源 ， 在 删除 选项 (DeleteOptions) 中 可 以 指定 优雅 删除 (Grace 
Deletion) 的 时 间 (GracePeriodSeconds ) ， 该 可 选项 表明 了 从 服务 端 接 
收 到 删除 请 求 到 资源 被 删除 的 时 间 间 隔 〈 单 位 为 秒 ) 。 不 同 的 类 别 
(Kind) 可 能 为 优雅 删除 时 间 (Grace Period) 申明 默认 值 。 用 户 提交 
的 优雅 删除 时 间 将 履 盖 该 默认 值 ， 包 括 值 为 0 的 优雅 删除 时 间 。 


(5) PUT/< 资 源 名 复数 格式 >/< 名 字 >: 通过 给 出 的 资源 名 和 客户 端 
提供 的 JSON 对 象 来 更 新 或 创建 资源 。 


(6) PATCH/< 资 源 名 复数 格式 >/< 名 字 >: 选择 修改 资源 详细 指定 
的 域 。 


对 于 PATCH 操作 ， 目 前 Kubernetes API 通 过 相应 的 HITP 首 


部 “Content-Type” 对 其 进行 识别 。 
目前 文 持 以 下 三 种 类 型 的 PATCH 操作 。 


(1) JSON Patch, Content-Type: application/json-patch+json。 在 
RFC6902 的 定义 中 ，JSON Patch 是 执行 在 资源 对 象 上 的 一 系列 操作 ， 例 
如 {“op”: “add”, “path”: “/a/b/c”, “value”: [“foo”，“bar”]}。 详 情 请 查 
看 RFC6902 说 明 ， 网 址 为 HTTPs: //tools.ietf.org/html/rfc6902. 


(2) Merge Patch, Content-Type: application/merge-json- 
patch+json。 在 RFC7386 的 定义 中 ，Merge Patch 必须 包含 对 一 个 资源 对 
象 的 部 分 描述 ， 这 个 资源 对 象 的 部 分 描述 就 是 一 个 JSON 对 象 。 该 JSON 
对 象 被 提交 到 服务 端 ， 并 和 服务 端的 当前 对 象 合 并 ， 从 而 创建 一 个 新 的 
对 象 。 详 情 请 查看 RFC73862 说 明 ， 网 址 为 
HTTPs: //tools.ietf.org/html/rfc7386。 


(3) Strategic Merge Patch, Content-Type: application/strategic- 
merge-patch+json。 Strategic Merge Patch 是 一 个 定制 化 的 Merge Patch 实 
现 。 接 下 来 将 详细 讲解 Strategic Merge Patch 。 


在 标准 的 JSON Merge Patch 中 ，JSON 对 象 总 是 被 合并 (merge) 
的 ， 但 是 资源 对 象 中 的 列表 域 总 是 被 蔡 换 的 。 通 单 这 不 是 用 户 所 希望 
的 。 例 如 ， 我 们 通过 下 列 定义 创建 一 个 Pod 资 源 对 象 : 





spec: 
containers: 
- name: nginx 


image: nginx-1.0 


接着 我 们 希望 添加 一 个 容器 到 这 个 Pod 中 ， 代 码 和 上 传 的 JSON 对 象 
如 下 所 示 : 


PATCH /api/vi/namespaces/default/pods/pod-name 
spec: 
containers: 
- name: log-tailer 


image: log-tailer-1.0 


如 果 我 们 使 用 标准 的 Merge Patch， 则 其 中 的 整个 容器 列表 将 被 单个 
的 “log-tailer” 容 右 所 替换 。 然 而 我 们 的 目的 是 两 个 容 右 列表 能 够 合并 。 


为 了 解决 这 个 问题 ，Strategic Merge Patch 通 过 添加 元 数据 到 API 对 
象 中 ， 并 通过 这 些 新 元 数据 来 决定 哪个 列表 被 合并 ， 哪 个 列表 不 被 合 
FF = LS ah eR 对 于 API 对 象 目 身 来 说 是 合法 的 。 

对 于 客户 端 来 说 ， 这 些 元 数据 作为 Swagger annotations 也 是 合法 的 。 在 
上 述 例 子 中 ， 癌 “containers” 中 添加 “patchStrategy” 域 ， 旦 它 的 值 

为 “merge”， 通 过 添加 “patchMergeKey”， 它 的 值 为 “name”。 也 就 是 

说 , “containers” 中 的 列表 将 会 被 合并 而 不 是 蔡 换 ， 合 并 的 依据 

为 “name” 域 的 值 。 








此 外 ，Kubernetes API 添 加 了 资源 变动 的 “观察 者 ”模式 的 API 接 口 。 


。 GET/watch/< 资 源 名 复数 格式 >: 随时 间 变 化 ， 不 断 接 收 一 连 串 的 
JSON 对 象 ， 这 些 JSON 对 象 记录 了 给 定 资源 类 别 内 所 有 资源 对 象 的 
变化 情况 。 

° CED Way ame 随时 间 变 化 ， 不 断 接 收 一 连 
串 的 JSON 对 象 ， 这 些 JSON 对 象 记录 了 某 个 给 定 资源 对 象 的 变化 情 


Jlo 





上 述 接口 改变 了 返回 数据 的 基本 类 别 ，watch 动 词 返回 的 是 一 连 趾 
的 JSON 对 象 ， 而 不 是 单个 的 JSON 对 象 。 并 不 是 所 有 的 对 象 类 别 都 支 
持 “观察 者 ”模式 的 API 接 口 ， 在 后 续 的 章节 中 将 会 说 明 哪些 资源 对 象 支 
持 这 种 接口。 








另外 ，Kubernetes 还 增加 了 HTTP Redirect 与 HITP Proxy 这 两 种 特殊 
的 API 接 口 ， 前 者 实现 资源 重 定 同 访问 ， 后 者 则 实现 HTTP 请 求 的 代理 。 





4.2.4 API 响 应 说 明 





API Server 啊 应 用 户 请 求 时 附带 一 个 状态 码 ， 该 状态 码 符 合 HTTP 规 
范 。 表 4.1 列 出 了 API Server 可 能 返回 的 状态 码 。 


4. 


44.1 API Server 可 能 返回 的 状态 人 码 





表明 请 求 完全 成 功 

Created 表明 创建 类 的 请 求 完全 成 功 

NoContent 表明 请 求 完全 成 功 ， 同 时 HITP 响应 不 包含 响应 体 。 
在 响应 OPTIONS 方法 的 HTTP 请 求 时 返回 
TemporaryRedirect | 表明 请 求 资源 的 地 址 被 改变 ， 建 议 客户 端 使 用 Location 首部 给 出 的 临时 URL 来 定位 资源 
BadRequest 表明 请 求 是 非法 的 ， 建 议 客户 不 要 重 试 ， 修 改 该 请 求 

Unauthorized 表明 请 求 能 够 到 达 服 务 端 ， 且 服务 端 能 够 理解 用 户 请 求 ， 但 是 拒绝 做 更 多 的 事情 ， 
因为 客户 端 必须 提供 认证 信息 。 如 果 客 户 端 提供 了 认证 信息 ， 则 返回 该 状态 码 ， 表 
明 服 务 端 指出 所 提供 的 认证 信息 不 合适 或 非法 

Forbidden 表明 请 求 能 够 到 达 服 务 端 ， 且 服务 端 能 够 理解 用 户 请 求 ， 但 是 拒绝 做 更 多 的 事情 ， 
因为 该 请 求 被 设置 成 拒绝 访问 。 建 议 客 户 不 要 重 试 ， 修 改 该 请 求 

NotFound 表明 所 请 求 的 资源 不 存在 。 建 议 客户 不 要 重 试 ， 修 改 该 请 求 

MethodNotAllowed | 表明 请 求 中 带 有 该 资源 不 支持 的 方法 。 建 议 客户 不 要 重 试 ， 修 改 该 请 求 












































编码 描 R 
Conflict 表明 客户 端 尝试 创建 的 资源 已 经 存在 ， 或 者 由 于 冲突 请 求 的 更 新 操作 不 能 被 完成 
UnprocessableEntity | 表明 由 于 所 提供 的 作为 请 求 部 分 的 数据 非法 ， 创 建 或 修改 操作 不 能 被 完成 
TooManyRequests 表明 超出 了 客户 端 访 问 频率 的 限制 或 者 服务 端 接收 到 多 于 它 能 处 理 的 请 求 。 建 议 客 
户 端 读 取 相应 的 Retry-After 首部 ， 然 后 等 待 该 首部 指出 的 时 间 后 再 重 试 
InternalServerError | 表明 服务 端 能 被 请 求 访问 到 ， 但 是 不 能 理解 用 户 的 请 求 ; 或 者 服务 端 内 产生 非 预期 
中 的 一 个 错误 ， 而 且 该 错误 无 法 被 认 知 ; 或 者 服务 端 不 能 在 一 个 合理 的 时 间 内 完成 
处 理 〈 这 可 能 由 于 服务 器 临时 负载 过 重 造 成 或 者 由 于 和 其 他 服务 器 通信 时 的 一 个 临 
时 通信 故障 造成 ) 
ServiceUnavailable | 表明 被 请 求 的 服务 无 效 。 建 议 客户 不 要 重 试 修改 该 请 求 
ServerTimeout 表明 请 求 在 给 定 的 时 间 内 无 法 完成 。 客 户 端 仅 在 为 请 求 指定 超时 (Timeout) 参数 时 
会 得 到 该 响应 










































































在 调用 API 接 口 发 生 错 误 时 ，Kubernetes 将 会 返回 一 个 状态 类 别 
(Status Kind) 。 下 和 面 是 两 种 常见 的 错误 场景 : 


C1) 当 一 个 操作 不 成 功 时 《例如 ， 当 服务 站 返回 一 个 非 2xx HTTP 


状态 码 时 ) 


. 
kd 


(2) 当 一 个 HITP DELETE 方 法 调用 失败 时 。 


状态 对 象 被 编码 成 JSON 格 式 ， 同 时 该 JSON 对 象 被 作为 请 求 的 响应 











体 。 该 状态 对 象 包含 人 和 机 器 使 用 的 域 ， 这 些 域 中 包含 来 自 API 的 关于 
失败 原因 的 详细 信息 。 状 态 对 象 中 的 信息 补充 了 对 HTTP 状 态 码 的 说 


明 。 例 如 : 


< 


{ 





curl -v -k -H "Authorization: Bearer WhCDvq4VPpYhrcfmF' 
GET /api/vi/namespaces/default/pods/grafana HTTP/1.1 
User-Agent: curl/7.26.0 

Host: 10.240.122.184 

Accept: */* 


Authorization: Bearer WhCDvq4vVPpYhrcfmF6ei7V9qlbqTubUc 


HTTP/1.1 404 Not Found 
Content-Type: application/json 
Date: Wed, 20 May 2015 18:10:42 GMT 


Content-Length: 232 


"kind": "Status", 


"apiVersion": "vi", 


"metadata": {}, 


"status": "Failure", 


"message": "pods \"grafana\"not found", 
"reason": "NotFound", 
"details": { 
"name": "grafana", 
"kind": "pods" 
ty 
"code": 404 
} 


“status” 域 包含 两 个 可 能 的 值 : Success 和 Failure。 
“message” 域 包含 对 错误 的 可 读 描 述 。 

“reason” 域 包含 说 明 该 操作 失败 原因 的 可 读 描 述 。 如 果 该 域 的 值 为 
空 ， 则 表示 该 域内 没有 任何 说 明 信 息 。“reason” 域 淤 清 HTTP 状 态 
码 ， 但 没有 窗 盖 该 状态 人 码 。 

“details” 可 能 包含 和 “reason” 域 相关 的 扩展 数据 。 每 个 “reason” 域 可 
以 定义 它 的 扩展 的 “details” 域 。 该 域 是 可 选 的 ， 返 回 数据 的 格式 是 
不 确定 的 ， 不 同 的 reason 类 型 返回 的 “details” 域 的 内 容 不 一 样 。 








4.3 ”使 用 Java 程 序 访 问 Kubernetes API 


本 节 介 绍 如 何 使 用 Java 程 序 访问 Kubernetes API。 在 Kubernetes 的 官 
网 上 列 出 了 多 个 访问 Kubernetes API 的 开源 项 目 ， 其 中 有 两 个 是 用 Java 语 
言 开发 工具 的 开源 项 目 ， 一 个 是 OSGI， 男 一 个 是 Fabric8。 在 本 节 所 列 
的 两 个 Java 开 发 例子 中 ， 一 个 是 基于 Jersey 的 ， 另 一 个 是 基于 Fabric8 
的 。 


4.3.1 Jersey 


Jersey 是 一 个 RESTful 请 求 服务 JAVA 框架 。 与 Struts 类 似 ， 它 可 以 和 
Hibernate、Spring 框 架 整 合 。 通 过 它 不 仪 方便 开发 RESTful Web 
Service， 而 且 可 以 将 它 作为 客户 端 方便 地 访问 RESTful Web Service 服 务 
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信 的 底层 通信 的 RESTful Web Services， 会 很 不 容易 。 为 了 能 够 简化 用 
Java 开 发 RESTful Web Service 及 其 客户 端的 流程 ， 业 界 设计 了 JAX-RS 
API. Jersey RESTful Web Services 框 架 是 一 个 开源 的 高 质量 的 框架 ， 它 
为 用 JAVA 语言 开发 RESTful Web Service 及 其 客户 端 而 生 ， 支 持 JAX-RS 
APIs。Jersey 不 仅 支 持 JAX-RS APIs， 而 且 在 此 基础 上 扩展 了 API 接 口 ， 
这 些 扩 展 更 加 方便 和 简化 了 RESTful Web Services 及 其 客户 端的 开发 。 


由 于 Kuberetes API Server 是 RESTful Web Service， 因 此 此 处 选用 
Jersey 框 架 开 发 RESTful Web Service 客 户 端 ， 用 来 访问 Kubernetes API. 
在 本 例 中 选用 的 Jersey 框 架 的 版 本 为 1.19， 所 涉及 的 Jar 包 如 图 4.6 所 示 。 























(éj commons-codec-1.2.jar 2015/9/13 11:10 Executable Jar File 30 KB 
l| commons-httpclient-3.1 jar 2015/9/13 11:09 Executable Jar File 298 KB 
l| commons-logging-1.0.4.jar 2015/9/13 11:10 Executable Jar File 38 KB 
| jackson-core-asl-1.9.2.jar 2015/2/11 5:41 Executable Jar File 223 KB 
|| jackson-jaxrs-1.9.2.jar 2015/2/11 5:41 Executable Jar File 18 KB 
l| jackson-mapper-asl-1.9.2,jar 2015/2/11 5:41 Executable Jar File 748 KB 
=| jackson-xc-1.9.2.jar 2015/2/11 5:41 Executable Jar File 27 KB 
|| jersey-apache-client-1.19 jar 2015/2/11 5:41 Executable Jar File 22 KB 
=| jersey-atom-abdera-1.19.jar 2015/2/11 5:41 Executable Jar File 20 KB 
(éj jersey-client-1.19jar 2015/2/11 5:41 Executable Jar File 131 KB 
lé] jersey-core-1.19.jar 2015/2/11 5:41 Executable Jar File 427 KB 
|=] jersey-guice-1.19jar 2015/2/11 5:41 Executable Jar File 16 KB 
\=| jersey-json-1.19 jar 2015/2/11 5:41 Executable Jar File 162 KB 
(é| jersey-multipart-1.19 jar 2015/2/11 5:41 Executable Jar File 3 KB 
(é| jersey-server-1.19.jar 2015/2/11 5:41 Executable Jar File 687 KB 
|S) jersey-servlet-1.19.jar 2015/2/11 5:41 Executable Jar File 126 KB 
é| jersey-simple-server-1.19.jar 2015/2/11 5:41 Executable Jar File 12 KB 
|| jersey-spring-1.19.jar 2015/2/11 5:41 Executable Jar File 18 KB 
(éj jettison-1.1.jar 2015/2/11 5:41 Executable Jar File 67 KB 
|S) jsr311-api-1.1.1.jar 2015/2/11 5:41 Executable Jar File 46 KB 
| oauth-client-1.19.jar 2015/2/11 5:4 Executable Jar File 15 KB 
lé] oauth-server-1.19.jar 2015/2/11 5:41 Executable Jar File 30 KB 
(é| oauth-signature-1.19 jar 2015/2/11 5:41 Executable Jar File 24 KB 

















图 4.6 ”本 例 所 涉及 的 Jar 包 
对 Kubernetes API 的 访问 包含 如 下 三 个 方面 。 
(1) 指明 访问 资源 的 类 型 。 


(2) 访问 时 的 一 些 选项 (参数 ) ， 比 如 命名 空间 、 对 象 的 名 称 、 
过 滤 方 式 〈 标 答 和 域 ) 、 子 目录 、 访 问 的 目标 是 否 是 代理 和 是 否 用 
watch 方 式 访问 等 。 





(3) 访问 的 方法 ， 比 如 增 、 删 、 改 、 查 。 


在 使 用 Jersey 框 架 访 问 Kubernetes API 之 前 ， 为 这 三 个 方面 定义 了 三 
个 对 象 。 第 1 个 定义 的 对 象 为 ResourceType， 它 定义 了 访问 资源 的 类 
型 ， 第 2 个 定义 的 对 象 是 Params， 它 定义 了 访问 API 时 的 一 些 选 项 ， 以 及 
通过 这 些 选 项 如 何 生 成 完整 的 URI; 第 3 个 定义 的 对 象 是 RestfulClient， 





它 古 一 个 接口 ， 该 接口 定义 了 访问 API 的 方法 (Method) 。 


ResourceType 是 一 个 ENUM 类 型 的 对 象 ， 定 义 了 16 种 资源 ， 代 码 如 


package com.hp.k8s.apiclient.imp; 


publicenum ResourceType { 
NODES("nodes"), 
NAMESPACES ("namespaces"), 
SERVICES("services"), 
REPLICATIONCONTROLLERS("replicationcontrollers"), 
PODS("pods"), 
BINDINGS("bindings"), 
ENDPOINTS("endpoints"), 
SERVICEACCOUNTS("serviceaccounts"), 
SECRETS("secrets"), 
EVENTS("events"), 
COMPOMENTSTATUSES("componentstatuses"), 
LIMITRANGES("limitranges"), 
RESOURCEQUOTAS("resourcequotas"), 
PODTEMPLATES("podtemplates"), 
PERSISTENTVOLUMECLAIMS("persistentvolumeclaims"); PER: 


private String type; 


private ResourceType(String type) { 


this.type = type; 


public String getType() { 


return type; 


Params 对 象 的 代码 如 下 : 


package com.hp.k8s.apiclient.imp; 


import java.io.UnsupportedEncodingException; 
import java.net.URLEncoder; 
import java.util.List; 


import java.util.Map; 


import org.apache.logging.log4j.LogManager; 


import org.apache.logging.1log4j.Logger; 


publicclass Params { 
privatestaticfinal Logger LOG = LogManager .getLogger ( 
private String namespace = null; 
private String name = null; 
private Map<String, String> fields = null; 
private Map<String, String> labels = null; 
private Map<String, String> notLabels = null; 


private Map<String, List<String>> inLabels = null; 


private Map<String, List<String>> notInLabels = null; 
private String json = null; 

private ResourceType resourceType = null; 

private String subPath = null; 

privateboolean isVisitProxy = false; 


privateboolean isSetWatcher = false; 


public String buildPath() { 
StringBuilder result = (isVisitProxy new St 
(isSetWatcher new StringB 
if (null != namespace) 


result.append("/namespaces/") .append( 


result.append("/").append(resourceType.getTypi 

if (null != name) 
result.append("/").append(name) ; 

if (null!=subPath) 


result.append("/").append(subPath) ; 


if (null != labels && !labels.isEmpty() || nu. 
|| null != inLabels && inLabe. 
|| null != fields && fields.s. 
StringBuilder labelSelectorStr = null 
StringBuilder fieldSelectorStr = null 

try { 
labelSelectorStr = builderLab 


fieldSelectorStr = builderFili 


} catch (UnsupportedEncodingException 


LOG.error(e1); 


if (labelSelectorStr.length() + field: 
result.append(" "); 
if (labelSelectorStr.length() > 0) { 


result.append("labelSelector= 


if (fieldSelectorStr.length() 


result.append(","); 


} 
if (fieldSelectorStr.length() > 0) { 


result .append("fieldSelector= 


return result.toString(); 


private StringBuilder builderLabelSelector() throws U 
StringBuilder result = new StringBuilder(); 
if (null != labels) { 

for (String key : labels.keySet()) { 
if (result.length() > 0) { 


"GBK" ) ) f 


result.append(","); 


result .append(URLEncoder ,enco 


if (null != notLabels) { 
for (String key : labels.keySet()) { 
if (result.length() > 0) { 


result.append(","); 


result .append(URLEncoder .enco 


if (null != inLabels) { 
for (String key : inLabels.keySet()) 
if (result.length() > 0) { 
result .append(URLEnco 


} 


result.append(URLENcoder ,enco 


if (null != notInLabels) { 
for (String key : inLabels.keySet()) 
if (result.length() > 0) { 


result .append(URLEnco 
} 


result.append(URLENcoder ,enco 


LOG.info("label result:" + result); 


return result; 


private StringBuilder builderFiledSelector() throws U 
StringBuilder result = new StringBuilder(); 
if (null != fields) { 

for (String key : fields.keySet()) { 
if (result.length() > 0) { 


result.append(","); 


result .append(URLEncoder.enco 


return result; 


private String listToString(List<String> list, String 
boolean isFirst = true; 
StringBuilder result = new StringBuilder(); 
for (String str : list) { 
if (isFirst) { 
result.append(str); 
isFirst = false; 
} else { 


result .append(delim).append(s 


return result.toString(); 


public String getNamespace() { 


return namespace, 


publicvoid setNamespace(String namespace) { 


this.namespace = namespace; 


public String getName() { 


return name; 


publicvoid setName(String name) { 


this.name = name; 


public Map<String, String> getFields() { 


return fields; 


publicvoid setFields(Map<String, String> fields) { 
this.fields = fields; 


public Map<String, String> getLabels() { 


return labels; 


publicvoid setLabels(Map<String, String> labels) { 
this.labels = labels; 


public String getJson() { 


return json; 


publicvoid setJson(String json) { 


this.json = json; 


public ResourceType getResourceType() { 


return resourceType; 


publicvoid setResourceType(ResourceType resourceType) 


this.resourceType = resourceType; 


public String getSubPath() { 


return subPath; 


publicvoid setSubPath(String subPath) { 


this.subPath = subPath; 


publicboolean isVisitProxy() { 


return isVisitProxy; 


publicvoid setVisitProxy(boolean isVisitProxy) { 


this.isVisitProxy = isVisitProxy; 


publicboolean isSetWatcher() { 


return isSetWatcher; 


publicvoid setSetWatcher(boolean isSetWatcher) { 


this.isSetWatcher = isSetWatcher; 


public Map<String, String> getNotLabels() { 


return notLabels; 


publicvoid setNotLabels(Map<String, String> notLabels 


this.notLabels = notLabels; 


public Map<String, List<String>> getInLabels() { 


return inLabels; 


publicvoid setInLabels(Map<String, List<String>> inLa 


this.inLabels = inLabels; 


public Map<String, List<String>> getNotInLabels() { 


return notInLabels; 


publicvoid setNotInLabels(Map<String, List<String>> n 


this.notInLabels = notInLabels; 


Params 对 象 包含 的 属性 说 明 如 表 4.2 所 示 。 
424.2 ”Params 对 象 包 含 的 属性 列表 


属 性 说 RA 
namespace String 类 型 属性 ， 指 明 资 源 所 在 的 命名 空间 ， 如 果 没 有 指定 该 值 ， 则 表明 访问 所 有 命名 空间 下 的 资源 对 象 
name Suing 类 型 属性 ， 在 访问 单个 资源 对 象 时 使 用 ， 如 果 没 有 指定 该 值 ， 则 表明 访问 该 类 资源 列表 
fields Map<String. String> 类 型 属性 ， 通 过 资源 对 象 的 域 值 过 滤 访 问 结果 
labels Map<String. String> 类 型 属性 ， 通 过 指定 的 标签 选择 器 列表 来 选择 资源 对 象 。 选 择 出 的 资源 对 象 包含 标签 列表 中 
所 列 的 标签 〈 即 Map 的 key) ， 且 所 选 资源 的 标签 的 value 和 标签 列表 中 的 value ffi (BI Map 的 value) 相等 
notLabels Map<Stiing. Stuing> 类 型 属性 ， 通 过 指定 的 标签 选择 器 列表 来 选择 资源 对 象 。 选 择 出 的 资源 对 象 包含 标签 列表 中 
所 列 的 标签 ( 即 Map 的 key)， 且 所 选 资源 的 标签 的 value 和 标签 列表 中 的 value {fi CL] Map 的 value) 不 相等 
inLabels Map<String. List<String>> 类 型 属性 ， 通 过 指定 的 标签 选择 器 列表 来 选择 资源 对 象 。Map 对 象 的 key 值 为 标 
签名 称 ，Map 对 象 的 value 值 为 该 标签 可 能 包含 的 值 
notInLabels | Map<String, List<String>> 类 型 属性 ， 通 过 指定 的 标签 选择 器 列表 来 选择 资源 对 象 。Map 对 象 的 key 值 为 标签 
名 称 ，Map 对 象 的 value 值 为 列表 ， 表 明 资源 对 象 包含 和 key 值 同名 的 标签 ， 且 这 些 标签 的 值 不 在 该 列表 中 
json String 类 型 属性 ， 在 创建 或 修改 资源 对 象 时 使 用 ， 用 于 向 API Server 提供 资源 对 象 的 定义 
resourceType | ResourceType 类 型 属性 ， 用 于 指明 访问 资源 对 象 的 类 型 
subPath String 类 型 属性 ， 用 于 指明 访问 资源 的 子 目 录 
isVisitProxy | Boolean 类 型 属性 ， 用 于 指明 是 否 通过 Proxy 的 方式 访问 资源 对 象 
isSetWatcher | Boolean 类 型 属性 ， 表 明 是 否 通过 Watcher 方式 访问 资源 对 象 












































Params 的 buildPath 方 法 用 于 构建 访问 URE 的 完整 路 径 。 


接口 对 象 RestfulClient 定 义 了 访问 API 接 口 的 所 有 方法 (Method) ， 
其 代码 列表 如 下 : 


package com.hp.k8s.apiclient; 


import com.hp.k8s.apiclient.imp.Params; 


publicinterface RestfulClient { 


public 
public 
public 
public 
public 
public 
public 
public 
public 


String 
String 
String 
String 
String 
String 
String 
String 


String 





get(Params params); // 获 得 单个 资源 对 象 


list(Params params); // 获 得 资源 对 象 列 表 








create(Params params); // 创 建 资源 对 象 
delete(Params params); // 删 除 某 个 资源 对 象 
update(Params params); // 部 分 更 新 某 个 资源 
updatewithMediaType(Params params,Strin 
replace(Params params); // 蔡 换 某 个 资源 对 
options(Params params); 


head(Params params); 


其 中 get 和 jist 方 法 对 应 Kubernetes “API 的 GET 方 法 ，create 方 法 对 应 
API 中 的 POST 方法 ，delete 方 法 对 应 API 中 的 DELETE 方 法 ，update 方 法 
对 应 API 中 的 PATCH 方法 :replace 方法 对 应 API 中 的 PUT 方法 ，options 
方法 对 应 API 中 的 OPTIONS 方 法 ;head 方 法 对 应 API 中 的 HEAD 方 法 。 








该 接口 的 基于 Jersey 框 架 的 实现 类 如 下 所 示 : 


package com.hp.k8s.apiclient.imp; 


import javax.ws.rs.core.MediaType; 


import org.apache.logging.1log4j.LogManager; 


import org.apache.logging.1log4j.Logger; 


Import 
Import 
Import 
Import 


Import 


com 


com. 


com 


com. 


com. 


.hp.k8s.apiclient.RestfulClient; 


sun.jersey.api.client.Client; 


.sun.jersey.api.client.WebResource; 


sun.jersey.api.client.config.DefaultClientCon 


sun.jersey.client.urlconnection.URLConnection' 


publicclass JerseyRestfulClient implements RestfulClient 


privatestaticfinal Logger LOG = LogManager .getLogger ( 


privatestaticfinal String METHOD_PATCH = "PATCH"; 


private String _baseUrl = null; 


Client _client = null; 


public JerseyRestfulClient(String baseUrl) { 


DefaultClientConfig config = new DefaultClien 


config.getProperties().put(URLConnectionClien 


_client = Client.create(config); 


this. baseUr = baseUrl; 


@Override 


public String get(Params params) { 


WebResource resource = _client.resource(_base 


String response = resource.accept (MediaType. Al 


LOG.info("Get one resource:\n" + response); 


return response; 


@Override 

public String list(Params params) { 
WebResource resource = _client.resource(_base 
LOG.info("URL:" + _baseUrl + params.buildPath 


String response = resource.accept (MediaType. Al 


return response; 


@Override 
public String create(Params params) { 
WebResource resource = _client.resource(_base 
LOG.info("URL:" + _baseUrl + params.buildPath 
LOG.info("Create resource:" + params.getJson( 
String response = (null == params.getJson()) 
resource.accept (MediaType. Al 
resource. type(MediaType.APP 


params.getJso 


return response; 


@Override 


public String delete(Params params) { 


WebResource resource = _client.resource(_base 
String response = resource.accept (MediaType. Al 
LOG.info("Detelet resource " + params.getReso 


+ response); 


return response; 


@Override 
public String update(Params params) { 


return updateWithMediaType(params, MediaType.. 


@Override 
public String updatewWithMediaType(Params params, Stri 
WebResource resource = _client.resource(_base 
LOG.info("URL:" + _baseUrl + params.buildPath 
LOG.info("Patch resource:" + params.getJson() 
String response = resource.type(mediaType) ,ac 
params.getJson()); 


LOG.info("Update resource " + params.buildPat 


return response; 


@Override 


public String replace(Params params) { 


WebResource resource = _client.resource(_base 
LOG.info("URL:" + _baseUrl + params.buildPath 
LOG.info("Replace resource:" + params.getJson 
String response = resource.type(MediaType.APP 

.put(String.class, params.get 


LOG.info("Replace resource " + params.buildPa 


return response; 


@Override 
public String options(Params params) { 
WebResource resource = _client.resource(_base 
String response = resource.type(MediaType.APP 
.options(String.class); 
LOG.info("Get options for resource " + params 


+ " result:\n" + response); 


return response; 


@Override 

public String head(Params params) { 
WebResource resource = _client.resource(_base 
String response = resource.accept (MediaType. T 
LOG.info("Get head for resource " + params.ge 


+ response); 


return response; 


@Override 
publicvoid close() { 


_client.destroy(); 


该 对 象 中 包含 如 下 代码 : 


config.getProperties().put(URLCoNnnectionClientHandler .PR 


该 段 代 码 的 作用 是 使 Jersey 客 户 端 能 够 文 持 除 标准 REST 方 法 外 的 方 
法 ， 比 如 PATCH 方法 。 该 段 代 码 能 访问 除 watcher 外 的 所 有 Kubernetes 
API 接 口 ， 在 后 续 的 章节 中 我 们 会 举例 说 明 如 何 访问 Kubernetes API. 


4.3.2 Fabric8 





Fabric8 包 含 多 款 工具 包 ，Kubernetes Client 只 是 其 中 之 一 ， 也 是 
Kubernetes 官 网 中 提 到 的 Java Client API 之 一 。 本 例子 代码 涉及 的 Jar 包 如 
图 4.7 所 示 。 

















图 4.7 ”例子 代码 涉及 的 Jar 包 





£| dnsjava-2.1.7 jar 2015/8/31 14:23 Executable Jar File 301 KB 
=) fabric8-utils-2.2.22 jar 2015/8/31 14:23 Executable Jar File 134 KB 
|= | jackson-annotations-2.6.0 jar 2015/8/31 16:27 Executable Jar File 46 KB 
=| jackson-core-2.6.1 jar 2015/8/31 16:28 Executable Jar File 253 KB 
=| jackson-databind-2.6.1 jar 2015/8/31 15:56 Executable Jar File 1,140 KB 
|= | jackson-dataformat-yaml-2.6.1 jar 2015/8/31 15:56 Executable Jar File 313 KB 
|=) jackson-module-jaxb-annotations-2.6.0jar 2015/8/31 16:24 Executable Jar File 32 KB 
(é| json-20141113 jar 2015/8/31 14:23 Executable Jar File 64 KB 
£| kubernetes-api-2.2.22 jar 2015/8/31 14:22 Executable Jar File 72 KB 
| 总 | kubernetes-client-1.3.8jar 2015/8/31 15:37 Fxecutable Jar File 2,262 KB 
|) kubernetes-model-1.0.12.jar 2015/8/31 15:56 Executable Jar File 2,308 KB 
=) log4j-api-2.3.jar 2015/8/31 16:18 Executable Jar File 133 KB 
l| log4j-core-2.3 jar 2015/8/31 15:56 Executable Jar File 808 KB 
é| log4j-sif4j-impl-2.3 jar 2015/8/31 15:56 Executable Jar File 23 KB 
| oauth-20100527 jar 2015/8/31 15:56 Executable Jar File 44 KB 
| openshift-client-1.3.2jar 2015/8/31 14:23 Executable Jar File 24 KB 
|| slf4j-api-1.7.12.jar 2015/8/31 15:56 Executable Jar File 32 KB 
=| sundr-annotations-0.0.25 jar 2015/8/31 15:56 Executable Jar File 146 KB 
(é| validation-api-1.1.0.Final.jar 2015/8/31 14:23 Executable Jar File 63 KB 


因为 该 工具 包 已 经 对 访问 Kubernetes API 客户 端 做 了 较 好 的 封装 ， 
因此 其 访问 代码 比较 简单 ， 其 具体 的 访问 过 程 会 在 后 续 的 章节 举例 说 
HA 。 


yo) 


Fabric 8 的 Kubernetes _ API 客户 端 工具 包 只 能 访问 Node、Service、 
Pod, Endpoints. Events. Namespace. PersistenetVolumeclaims, 


PersistenetVolume. ReplicationController, ResourceQuota. Secret#ll 


ServiceAccount 这 几 个 资源 类 型 ， 不 能 使 用 OPTIONS 和 HEAD 方 法 访问 
资源 ， 且 不 能 以 代理 方式 访问 资源 ， 但 其 对 以 watcher 方 式 访 问 资源 做 了 
很 好 的 支持 。 


4.3.3 ”使 用 说 明 


首先 ， 举 例 说 明 对 API 资 源 的 基本 访问 ， 也 就 是 对 资源 的 增 、 删 、 
改 、 查 ， 以 及 蔡 换 资源 的 status。 其 中 会 单独 对 Node 和 Pod 的 特殊 接口 做 
举例 说 明 。 表 4.3 列 出 了 各 资源 对 象 的 基本 API 接 口 。 


表 4.3 ”各 资源 对 象 的 基本 API 接 口 


URL Path 说 AA 
/api/v1/nodes 获取 Node 列表 
/api'v1/nodes 创建 一 个 Node 1B 
/api/v1/nodes/ {name} 删除 一 个 Node 对 象 
/api/v1/nodes/ {name} 获取 一 个 Node 对 象 
/api/v1/nodes/ {name} 部 分 更 新 一 个 Node 对象 
/api/v1/nodes/ {name} 替换 一 个 Node 对 象 














/api/v1/namespaces 获取 Namespace 列表 


/api/v1/namespaces 创建 一 个 Namespace 对 象 





/api/v1/namespaces/ {name} 删除 一 个 Namespace 对 象 





/api'v1/namespaces/ {name} 获取 一 个 Namespace 对 象 





/api/v1/namespaces/ {name} 部 分 更 新 一 个 Namespace 对 象 








NAMESPACES 
/api/v1/namespaces/ {name} 替换 一 个 Namespace 对 象 


替换 一 个 Namespace 对 象 的 最 终 方 | 在 Fabric8 中 没有 
EMS. 实现 
在 Fabrics 中 没有 


/api/v1/namespaces/ {name}/finalize 


‘api/v1/namespaces/{name}/status | 替换 一 个 Namespace 对 象 的 状态 
/api/v1 /services 获取 Service 列表 


/api/vl/services 创建 一 个 Service HF 


/api/v1/namespaces/{namespace}/se | 获取 某 个 Namespace 下 的 Service 列 








TVices 表 
1 apes a {namespace} /se 在 某 个 Namespace 下 创建 列表 
TVices 
/lapi'vl/namespaces/{namespace}/se | 删除 菜 个 Namespace 下 的 
rvices/ {name} Service 对 象 
/api/v1/namespaces/{namespace}/se | 获取 某 个 Namespace 下 的 
rvices/ {name} Service Xi% 
/api/v1/namespaces/{namespace}/se | 部 分 更 新 某 个 Namespace 下 的 
rvices/ {name} Service Xj% 








/api/v1/namespaces/{namespace}/se | # % $ 4+ Namespace 下 的 一 











rvices/ {name} Service FB 








续 表 
资源 美 型 
GET Jiapivieplieationeonnollers [uence | 

创建 一 个 RC a 一 一 


/aplvljnzamespacesl{namespacej/re 
GET 获取 某 个 Namespace 下 的 RC 列表 
plicationcontrollers 
poe lapi/vl/namespaces/ {namespace} /re | 在 某 个 Namespace 下 创建 一 个 RC 
plicationcontrollers 对 象 
REPLICATIONC /apv'v1 /namespaces/ {namespace} /re 
me | Me | 出 除 某 个 Namespace 下 的 RC WR 
ONTROLLERS plicationcontrollers/ {name} 
f$ uw 4 
/apv'v1 ‘namespaces! {namespace}/re 获取 某 个 Namespace Fit RC 对 象 
plicationcontrollers/ {name} 


fapi/v1 ‘pods 创建 一 个 Pod WR 
GET /apu'v] ‘namespaces! {namespace}/pods | 获取 某 个 Namespace 下 的 Pod 列 


| 

EE 

SS 

/apa'v ‘namespaces! {namespace} /pods 
— 
| 

ea a | 
ds/{name} Pod 对 象 

rt 
ds/{name} 

a ee 
—— 
ds/ {name} binding 象 的 

= 上 一 
ds/{name}/exec 对 象 ， 并 执行 exec 

= aa alte 
ds/{name}/exec WR, FET exec 


获取 一 个 Pod 列表 | 
È 





续 表 

| 资源 类 型 | 方 法 | Urean | 说 用 | 备注 | 
ds/{name}/log WR. FRM log 日 志 信 息 实现 
ds/{name} /portforward 对 象 ， 并 实现 端口 转发 实现 

a | 
ds/{name}/portforward 对 象 ， 并 实现 端口 转发 实现 

post [iapivivindings | ART Binding | 

BINDINGS 


‘api'v] Mmamespaces/{namespace}/bi | 在 某 个 Namespace 下 创建 一 个 
ndings Binding 对 象 


IRIN Endpoint 列表 a 
[post |/apitvi/endpoins | 创建 -个 Fnapoint 对 条 


= ‘api'v1/mamespaces/{namespace}/en | 获取 某 个 Namespace 下 的 Endpoint 
dpoints 对 象 列表 





获取 Serviceaeeount 列表 


dpoints {name} 
/apilnamespacesf{fnamespacej/en | RIEA Namespace 下 的 Endpoint 
dpoints/ {name} WR 


创建 一 个 Servicesceount R 


/api'v1 /namespaces/ {namespace} 获取 某 个 Namespace 下 的 
rviceaccounts Serviceaccount 对 象 列表 


‘apv'v] /namespaces/ {namespace} 删除 某 个 Namespace 下 的 一 个 
as 
‘apu'v1 mamespaces/{namespace}/se | 获取 某 个 Namespace 下 的 一 个 
= Tviceaccounts/ {name} 


(se 
SERVICEACCOU fapi'v] /mamespaces/{namespace}/se | 在 某 个 Namespace 下 创建 一 个 
NTS rviceaccounts Serviceaccount 对 象 

(se 


suas [sa] men [a _ 


续 表 
peene lapi'vl/namespaces/ {namespace} /se | 部 分 更 新 某 个 Namespace 下 的 一 
rviceaccounts/ {name} Serviceaccount 对 象 
/api'v1 /mamespaces/{namespace}/se | 苍 换 某 个 Namespace 下 的 一 个 


rviceaccounts/ {name} Serviceaccount 对 象 


本 Te a r 1 
ti toca = 


ES 
‘api/v] /namespaces/ {namespace} /se | 在 某 个 Namespace 下 创建 一 个 Secret 

a i | 

a ae 
crets/ {name} WR 

= ar 
crets/ {name} WR 
/api'v1 namespaces! {namespace} /se | 部 分 更 新 某 个 Namespace 下 的 一 个 

= Ee ae | 

Pe 
crets/ {name} WR 


TER 
= A Bret 


= = 

ents! {name} 

= Ae | 
ene 对 象 


/apilfaamespacesf{fnamespacejjev | 部 分 更 新 某 个 Namespace 下 的 一 个 
ents’ {name} Event 对 名 


Pr lapi'vl/namespaces/ {namespace} /ev | HEIA Namespace 下 的 一 个 Event 
ents! {name} 对 象 


PATCH 


a aaa ee a 


COMPONENTST 
= lapi'vl/namespaces/ {namespace} /co | 获取 某 个 Namespace 下 的 Component 
mponentstatuses Status 列表 





续 表 
资源 类 型 |a 法 | urpean | aam | 备注 | 
ee fapi'vl/namespaces/ {namespace} /co | 获取 某 个 Namespace 下 的 一 个 
mponentstatuses/ {name} ComponentStatus 对 象 


7 imine WR — 
Po a | | 


2d 
mutranges 列表 
| 
mutranges LimitRange 对 象 
mutranges/ {name} LimitRange 对 象 
ed 
mitranges/ {name} LimitRange 1) 
‘api/v1 /mamespaces/ {namespace} /li | 部 分 更 新 某 个 Namespace 下 的 一 个 
oe ee | 
= — ll 
mutranges/ {name} LimitRange 对 象 





S OAT 
ie 


Si fapi'vl/namespaces/ {namespace} /re | 获取 某 个 Namespace 下 的 Resource 
sourcequotas Quota 列表 


sourcequotas Resource Quota X. 
/api'v1 /mamespaces/{namespace}/re | Mf 除 某 个 Namespace 下 的 一 个 
RESOURCEQUO apop Resource Quota 对 象 

sourcequotas/ {name} Resource Quota 对 象 

oo 
sourcequotas/ {name} Resource Quota 对 象 

= a 
sourcequotas/ {name} Resource Quota 对 象 
sourcequotas/ {name} /status Resource Quota 对 象 状 态 实现 


续 表 
SET |iapivipodemplates | sk PodTemplte i | | 
创建 ~ 个 oaTemplate 对 象 | | 


dtemplates PodTemplate 列表 
dtemplates PodTemplate 对 象 


/api/v1 ‘namespaces! {mamespace}/po | IBE Namespace 下 的 一 个 
dtemplates/{name} PodTemplate 对 象 


‘api'v1 ‘mamespaces/{namespace}/po | 获取 某 个 Namespace 下 的 一 个 
ES | 
dtemplates/ {name} PodTemplate 对 象 


‘api'v] /mamespaces/{namespace}/po | H3 3^ Namespace 下 的 一 个 
PodTemplate 对 象 


获取 PersistentVolume 列表 
创建 一 个 PersistentVolume X$ 
/api'vl /persistentvolumes/ {name} 删除 一 个 PersistentVolume 对 象 


部 分 更 新 一 个 PersistentVolume 对 象 EE 
普 换 一 个 Persistentvolune 对 销 | | 


€ Fabric 中 没有 
替换 一 个 PersistentVolume 对 象 状态 
a 





PODTEMPLATES | DELETE 


/api'vl /persistentvolumeclaims 获取 Persistent VolumeClaim 列表 a 
POST BIR — A PersistentVolumeClaim 31B] | 


—| 
VolumeClaim 列表 
TER Namespace 下 创建 一 个 | | 
rsistentvolumeclaims/ {name} Persistent VolumeClaim X & 
lapi'vl/namespaces/ {namespace} /pe | 获取 某 个 Namespace 下 的 一 个 [| | 
rsistentvolumeclaims/ {name} Persistent VolumeClaim 对 象 
parce | ‘api'v] namespaces! {namespace}/pe | 部 分 更 新 某 个 Namespace 下 的 一 || 
rsistentvohumeclaims! {name} 个 Persistent VolumeClaim 对 象 


URL Path 说 RA 
/api/v1/namespaces/{namespace}/pe | 替换 某 个 Namespace 下 的 一 个 





rsistentvolumeclaims/ {name} Persistent VolumeClaim 对 象 
/api/v1/namespaces/{namespace}/pe | 蔡 换 某 个 Namespace 下 的 一 个 在 Fabric8 中 没有 


rsistentvolumeclaims/{name}/status | Persistent VolumeClaim 对 象 状 态 实现 











首先 ， 举 例 说 明 如 何 通过 API 接 口 来 创建 资源 对 象 。 我 们 需要 创建 
访问 API Server 的 客户 端 ， 基 于 Jersey 框 架 的 代码 如 下 : 


RestfulClient _restfulClient = new JerseyRestfulClient("| 


HEF, http://192.168.1.128: 8080 为 API Server 的 地 址 。 基 于 Fabric8 
框架 的 代码 如 下 : 


Config _conf = new Config(); 


KubernetesClient_kube = new DefaultKubernetesClient ("htt 





分 别 通过 上 面 的 两 个 客户 端 创建 Namespace 资 源 对 象 ， 基 于 Jersey 框 
架 的 代码 如 下 : 


privatevoid testCreateNamespace() { 
Params params = new Params(); 
params.setResourceType(ResourceType.NAMESPACE: 


params.setJson(Utils.getJson("namespace.json" 


LOG.info("Result:" + _restfulClient.create(pa 


其 中 ，“namespace.json” 为 创建 Namespace 资 源 对 象 的 JSON 定 义 ， 代 
码 如 下 : 


"kind":"Namespace", 
"apiVersion":"vi", 
"metadata": { 


"name": "ns-sample" 


基于 Fabric8 框 架 的 代码 如 下 : 


privatevoid testCreateNamespace() { 
Namespace ns = new Namespace(); 
ns.setApiVersion(ApiVersion.V_1); 
ns.setKind("Namespace"); 
ObjectMeta om = new ObjectMeta(); 
om.setName("ns-fabric8"); 


ns.setMetadata(om) ; 


_kube.namespaces().create(ns); 


LOG.info(_kube.namespaces().list().getItems() 


由 于 Fabric8 框 架 对 Kubernetes ”API 对 象 做 了 很 好 的 封装 ， 对 其 中 的 
大 量 对 象 都 做 了 定义 ， 所 以 用 户 可 以 通过 其 提供 的 资源 对 象 去 定义 
Kubernetes API 对 象 ， 例 如 上 面 例子 中 的 Namespace 对 象 。Fabric8 框 架 中 
的 kubernetes-model 工 具 包 用 于 API 对 象 的 封装 。 在 上 面 的 例子 中 ， 通 过 
Fabric8 框 架 提供 的 类 创建 了 一 个 名 为 “ns-fabric8” 的 命名 空间 对 象 。 


接 下 来 我 们 会 通过 基于 Jeysey 框 架 的 代码 去 创建 两 个 Pod 资 源 对 
象 。 在 两 个 例子 中 ， 一 个 是 在 上 面 创建 的 “ns-sample”Namespace 中 创建 
Pod 资 源 对 象 ， 男 一 个 是 为 后 续 创建 “cluster service” 而 创建 的 Pod 资 源 对 


象 。 由 于 基于 Fabric8 框 架 创建 Pod 资 源 对 象 的 方法 很 简单 ， 因 此 不 再 用 
Fabric8 框 架 对 上 述 两 个 例子 做 说 明 。 通 过 基于 Jersey 框 架 创 建 这 两 个 Pod 
资源 对 象 的 代码 如 下 : 


privatevoid testCreatePod() { 
Params params = new Params(); 
params.setResourceType(ResourceType.PODS) ; 
params.setJson(Utils.getJson("podInNs.json") ) 
params.setNamespace("ns-sample"); 


LOG.info("Result:" + _restfulClient.create(pa 


params.setJson(Utils.getJson("pod4ClusterServ 


LOG.info("Result:" + _restfulClient.create(pa 


其 中 ，podInNs.json 和 pod4ClusterService.json 是 创建 两 个 Pod 资 源 对 
象 的 定义 。podInNs.json 文 件 的 内 容 如 下 : 


{ 

"kind":"Pod", 
"apiVersion": "vi", 
"metadata": { 


"name" :"pod-sample-in-namespace", 


"namespace": "ns-sample" 
ty 
"spec": { 


"containers": [{ 


"name":"mycontainer", 
"image": "kubeguide/redis-master" 


}] 


pod4ClusterService.json 文 件 的 内 容 如 下 : 


{ 
"kind":"Pod", 
"apiVersion": "vi", 
"metadata": { 


"name":"pod-sample-4-cluster-service", 


"namespace": "ns-sample", 
"labels": { 

"k8s-cs": "kube-cluster-service", 

"k8s-test": "kube-cluster-test", 
"k8s-Sample-app": "kube-service-sample", 
"kkk": "bbb" 

} 

ty 

"spec": { 


"containers": [{ 
"name":"mycontainer", 


"image": "kubeguide/redis-master" 


}] 





下 面 的 例子 代码 用 于 获取 Pod 资 源 列表 ， 其 中 第 1 部 分 代码 用 于 获取 
所 有 的 Pod 资 源 对 象 ， 第 2、3 部 分 代码 主要 是 列举 如 何 使 用 标签 选择 Pod 
资源 对 象 ， 最 后 一 部 分 代码 用 于 举例 说 明 如 何 使 用 field 选 择 Pod 资 源 对 
象 。 代 码 如 下 : 


privatevoid testGetPodList() { 
Params params = new Params(); 
params.setResourceType(ResourceType.PODS) ; 


LOG.info("Result:" + _restfulClient.list(parai 


Map<String, String> labels = new HashMap<Stri 
labels.put("k8s-cs", "kube-cluster-service"); 
labels.put("k8s-sample-app", "kube-service-sal 
params.setLabels(labels); 

LOG.info("Result:" + _restfulClient.list(parai 


params.setLabels(null); 


Map<String, List<String>> inLabels = new Hash 
List list = new ArrayList<String>()j; 
list.add("kube-cluster-service"); 
list.add("kube-cluster"); 
inLabels.put("k8s-cs", list); 
params.setInLabels(inLabels); 
LOG.info("Result:" + _restfulClient.list(parai 


params.setInLabels(null); 


Map<String, String> fields = new HashMap<Stri 


fields. 
params. 


params. 


put("metadata.name", "pod-sample-4-clu: 
setNamespace("ns-sample"); 


setFields(fields); 


LOG.info("Result:" + _restfulClient.list(parai 


接 下 来 的 例子 代码 用 于 蔡 换 一 个 Pod 对 象 ， 在 通过 Kubernetes API 替 








换 一 个 Pod 资 源 对 象 时 需要 注意 两 点 : 


(1) 在 蔡 换 该 资源 对 象 前 ， 先 从 API 中 获取 该 资源 对 象 的 JSON 对 
象 ， 然 后 在 该 JSJON 对 象 的 基础 上 修改 需要 替换 的 部 分 ; 


(2) 在 Kubermetes _ API 提供 的 接口 中 ，PUT 方 法 (replace) 只 支持 


蔡 换 容器 的 image 部 分 。 


代码 如 下 : 


privatevoid testReplacePod() { 


Params 


params. 
params. 
params. 


params. 


params = new Params(); 
setNamespace("ns-sample"); 
setName("pod-sample-in-namespace" ); 
setJson(Utils.getJson("pod4Replace.jso 


setResourceType(ResourceType.PODS) ; 


LOG.info("Result:" + _restfulClient.replace(p 


其 中 ，pod4Replace.json 的 内 容 如 下 : 


{ 
"kind": "Pod", 
"apiVersion": "vi", 


"metadata": { 


"name": "pod-sample-in-namespace", 
"namespace": "ns-sample", 
"selfLink": "/api/vi/namespaces/ns-sample/pods/pod-sampl 


"uid": "O084Ff63e-59d3-11e5-8035-000c2921ba71", 
"resourceVersion": "45450", 
"creationTimestamp": "2015-09-13T04:51:01Z" 

ty 
"spec": { 
"volumes": [ 

{ 

"name": "default-token-szoje", 
"secret": { 


"secretName": "default-token-szoje" 


J 


]， 


"containers": [ 
"name": "mycontainer", 
"image": "centos", 


"resources": {}, 


"volumeMounts": [ 
{ 
"name": "default-token-szoje", 
"readOnly": true, 
"mountPath": "/var/run/secrets/kubernetes.io/serviceacco 
} 
] ， 


"terminationMessagePath": "/dev/termination-log", 
"imagePullPolicy": "IfNotPresent" 
} 
], 


"restartPolicy": "Always", 
"dnsPolicy": "ClusterFirst", 
"serviceAccountName": "default", 
"serviceAccount": "default", 
"nodeName": "192.168.1.129" 
ty 

"status": { 
"phase": "Running", 
"conditions": [ 

{ 
"type": "Ready", 
"status": "True" 

} 


]， 
"hostIP": "192.168.1.129", 


"podIP": "10.1.10.66", 


"startTime": "2015-09-11T15:17:28Z", 
"containerStatuses": [ 
{ 
"name": "mycontainer", 
"state": { 
"running": { 
"startedAt": "2015-09-11T15:17:30Z" 
} 


ty 
"lastState": {}, 


"ready": true, 

"restartCount": 0, 

"image": "kubeguide/redis-master", 

"imageID": "docker://5630952871a38cddf fda9ec611f5978ab09 
"containerID": "docker://7bf0d454c367418348711556e667fd1 


5 


接 下 来 的 两 个 例子 实现 了 4.2.4 节 中 提 到 的 两 种 Merge 方 式 : Merge 
Patch 和 Strategic Merge Patch 。 


第 1 种 Merge 方 式 的 示例 如 下 : 


privatevoid testUpdatePod1() { 


Params params = new Params(); 


params.setNamespace("ns-sample"); 
params.setName("pod-sample-in-namespace" ); 
params.setJson(Utils.getJson("pod4MergeJsonPa 


params.setResourceType(ResourceType.PODS) ; 


LOG.info("Result:" + _restfulClient.updatewit 


其 中 ，pod4MergeJsonPatch.json 的 内 容 如 下 : 


{ 
"metadata": { 
"labels": { 
"k8s-cs": "kube-cluster-service", 
"k8s-test": "kube-cluster-test", 
"k8s-sa5555mple-app": "kube-service-sample", 


"kkk": "bbb4444" 
} 


第 2 种 Merge 方 式 (Strategic Merge Patch) 的 示例 如 下 : 


privatevoid testUpdatePod2() { 
Params params = new Params(); 
params.setNamespace("ns-sample"); 


params.setName("pod-sample-in-namespace"); 


params.setJson(Utils.getJson("pod4StrategicMe 


params.setResourceType(ResourceType.PODS) ; 


LOG.info("Result:" + _restfulClient.updatewit 


其 中 ，pod4StrategicMerge.json 的 内 容 如 下 : 


{ 

"spec": { 

"containers": [{ 
"name":"mycontainer", 
"image":"centos", 
"patchStrategy":"merge", 


"yatchMergeKey": "name" 


}] 


接 下 来 实现 了 修改 Pod 资 源 对 象 的 状态 ， 人 代码 如 下 : 


privatevoid testStatusPod() { 
Params params = new Params(); 
params.setNamespace("ns-sample"); 
params.setName("pod-sample-in-namespace"); 
params.setSubPath("/status"); 


params.setJson(Utils.getJson("pod4Status.json 


params.setResourceType(ResourceType.PODS) ; 


_restfulClient.replace(params); 


其 中 ，pod4Status.json 的 内 容 如 下 : 


{ 
"kind": "Pod", 
"apiVersion": "vi", 


"metadata": { 


"name": "pod-sample-in-namespace", 
"namespace": "ns-sample", 
"selfLink": "/api/vi/namespaces/ns-sample/pods/pod-sampl 


"uid": "ad1id803f -59ec-11e5-8035-000c2921ba71", 
"resourceVersion": "51640", 
"creationTimestamp": "2015-09-13T07:54:35Z" 

ty 
"spec": { 
"volumes": [ 

{ 

"name": "default-token-szoje", 
"secret": { 


"secretName": "default-token-szoje" 


} 


], 


"containers": [ 
{ 

"name": "mycontainer", 
"image": "kubeguide/redis-master", 
"resources": {}, 
"volumeMounts": [ 

{ 
"name": "default-token-szoje", 
"readOnly": true, 
"mountPath": "/var/run/secrets/kubernetes.io/serviceacco 

} 

], 


"terminationMessagePath": "/dev/termination-log", 
"imagePullPolicy": "IfNotPresent" 
} 
], 


"restartPolicy": "Always", 
"dnsPolicy": "ClusterFirst", 
"serviceAccountName": "default", 
"serviceAccount": "default", 
"nodeName": "192.168.1.129" 

ty 
"status": { 
"phase": "Unknown", 
"conditions": [ 

{ 

"type": "Ready", 


"status": "false" 


J 


]， 
"hostIP": "192.168.1.129", 


"podIP": "10.1.10.79", 
"startTime": "2015-09-11T18:21:02Z", 
"ContainerStatuses": [ 
{ 
"name": "mycontainer", 
"State": { 
"running": { 
"startedAt": "2015-09-11T18:21:03Z" 
} 


ty 
"lastState": {}, 


"ready": true, 

"restartCount": 0, 

"image": "kubeguide/redis-master", 

"imageID": "docker://5630952871a38cddf fda9ec611F5978abo9: 
"containerID": "docker ://b0e2312643e9a4b59cf1ff5fb7a8468ı 


} 


E RKI S AA PodHlogH sake, AU F: 


privatevoid testLogPod() { 
Params params = new Params(); 
params.setNamespace("ns-sample"); 
params.setName("pod-sample-in-namespace"); 
params.setSubPath("/log"); 


params.setResourceType(ResourceType.PODS) ; 


_restfulClient.get(params); 


下 面 通 过 API 访 问 Node 的 多 种 接口 ， 代 码 如 下 : 


privatevoid testPoxyNode() { 
Params params = new Params(); 
params.setName("192.168.1.129"); 
params.setSubPath("pods") ; 
params.setVisitProxy(true); 
params.setResourceType(ResourceType.NODES) ; 
_restfulClient.get(params) ; 

params = new Params(); 

params.setName("192.168.1.129"); 

params.setSubPath("stats"); 

params.setVisitProxy(true); 

params.setResourceType(ResourceType.NODES) ; 


_restfulClient.get(params); 


params = new Params(); 
params.setName("192.168.1.129"); 
params.setSubPath("spec"); 
params.setVisitProxy(true); 
params.setResourceType(ResourceType.NODES) ; 


_restfulClient.get(params); 


params = new Params(); 
params.setName("192.168.1.129"); 
params.setSubPath("run/ns-sample/pod/pod- samp 
params.setVisitProxy(true); 
params.setResourceType(ResourceType.NODES) ; 


_restfulClient.get(params); 


params = new Params(); 
params.setName("192.168.1.129"); 
params.setSubPath("metrics"); 
params.setVisitProxy(true); 
params.setResourceType(ResourceType.NODES) ; 


_restfulClient.get(params); 








最 后 ， 举 例 说 明 如 何 通过 API 删 除 资源 对 象 pod， 人 代码 如 下 : 


privatevoid testDetetePod() { 
Params params = new Params(); 


params.setNamespace("ns-sample"); 


params.setName("pod-sample-in-namespace"); 
params.setResourceType(ResourceType.PODS) ; 


LOG.info("Result:" + _restfulClient.delete(pa 


通过 API 接 口 除 了 能 够 对 资源 对 象 实现 前 面 列 出 的 基本 操作 外 ， 还 
涉及 两 类 特殊 接口 ， 一 类 是 WATCH， 一 类 是 PROXY。 这 两 类 特殊 接口 


所 包含 的 接口 如 表 4.4 所 示 。 


AAA ”两 类 特殊 接口 所 包含 的 接口 


URL Path 


说 了 明 





/api/v1/watch/nodes 


监听 所 有 节点 的 变化 





/api/v1/watch/nodes/ {name} 


监听 单个 节点 的 变化 





DELETE 


/api/v1/proxy/nodes/ {name}/{path:*} 


代理 DELETE 请 求 到 节点 的 某 个 子 
J% 








/api/v1/proxy/nodes/ {name}/{path:*} 


代理 GET 请 求 到 节点 的 某 个 子 目 录 








/api/v1/proxy/nodes/ {name}/ {path:*} 


代理 HEAD 请求 到 节点 的 某 个 子 目 
ot 





/api/v1/proxy/nodes/ {name} / {path:*} 


代理 OPTIONS 请 求 到 节点 的 某 个 
了 目录 





/api/v1/proxy/nodes/ {name}/{path:*} 


代理 POST 请 求 到 节点 的 某 个 子 目 
录 





/api/v1/proxy/nodes/{name}/{path:*} 


代理 PUT 请 求 到 节点 的 某 个 子 目录 





/api/v1/proxy/nodes/ {name} 


代理 DELETE 请 求 到 节点 





/api/v1/proxy/nodes/ {name} 


代理 GET 请 求 到 节点 





/api/v1/proxy/nodes/ {name} 


代理 HEAD 请 求 到 节点 





OPTIONS 


/api/v1/proxy/nodes/ {name} 


代理 OPTIONS 请 求 到 节点 





POST 


/api/v1/proxy/nodes/ {name} 


代理 POST 请 求 到 节点 





PUT 


/api/v1/proxy/nodes/ {name} 


代理 PUT 请 求 到 节点 








SERVICES 





WATCH 


/api/v1/watch/services 


监听 所 有 Service 的 变化 











/api/v1/watch/namespaces/ {namespace}/ 


services 





监听 某 个 Namespace 下 所 有 Service 
的 变化 





资源 类 型 | 类 别 | 方 法 | ump | 说 用 ü ü O 


/apiivliwatch/n sf 1 
en EEA Service 的 变化 
services/ {name} 


lapi'vliproxy/namespaces/ {namespace}/ | 代理 DELETE 请 求 到 Service 的 某 
services/ {name}/{path:*} FAR 

fapi'v] /proxy/namespaces/{namespace}/ | 代理 GET 请 求 到 Service 的 某 个 子 
services! {name}/{path:*} Ax 


De 
services/ {name} /{path:*} FAR 
个 子 目录 


续 表 
说 A 





lapiivl/proxy/namespaces/ {mamespace}/ 
Are spaces' (namespace) | 代理 HEAD i Ril Service 
services/ {name} 


fapilvl! h J | 

options | "Pn Proxyínamespaces/ {namespace}! | 代理 OPTIONS 请 求 到 Service 
services/ {name} 
/apv'v1/proxy/namespaces! {namespace}/ ~ 

POST : 代理 POST 请 求 到 Service 
services/ {name} 
/apy'v1h h 3] / {namesp: 4 

UT ame » ea aaa gz 代理 PUT 请 求 到 Service 


p 


KRE RC 的 变化 


AA ‘api/v1/watch/namespaces!{mamespace}/ | 监听 某 个 Namespace 下 所 有 RC 的 
replicationcontrollers 变化 
/apivl/watch/n sl / 

GET = a ‘acacia 监听 某 个 RC 的 变化 
replicationcontrollers/ {name} 


S TT 


fapi'vl/watch/namespaces/ {namespace}? | 监听 某 个 Namespace 下 所 有 Pod 的 
pods 变化 





续 表 
x ajs a) oem T  wn 
lapi/v lA J 1 
pods/ {name} 
aaa api/v 1 /namespaces/{namespace}/pods/{ | {RI DELETE 请 求 到 Pod 的 某 个 子 
name}/proxy/ {path:*} 目录 
fapi'vl A } 
apy linamespaces/ (namespace (| 代理 GET 请 求 到 Pod 的 某 个 子 目 录 
name}/proxy/ {path:*} 
/api'v 1 /mamespaces/{namespace}/pods/{ | I HEAD 请 求 到 Pod 的 某 个 子 目 
name}/proxy/ {path-*} 录 
i /api'v lnamespaces/{namespace}/pods/{ 代理 OPTIONS 请 求 到 Pod 的 某 个 
name}/proxy/ {path:*} 子 目录 
i /apivlinamespaces/{namespace}ipods/{ | 代理 POST 请 求 到 Pod HATTA 
name}/proxy/ {path:*} 录 
ily Ipods! 
/api'v l/mamespaces/ {namespace }/pods/ { 代理 PUT 请 求 到 Pod 的 某 个 子 目录 
name }/proxy/ {path:*} 
FA / 
om | /api/v l/namespaces/ {namespace}/pods/{ 代理 DELETE 请 求 到 pod 
name}/proxy 
TS | 
(apilvl/namespaces/{namespace}/pods/{ 代理 GET 请 求 到 Pod 
name}/proxy 
uel j 4 } 
PROXY Ea /api’v 1 ‘namespaces! {namespace }/pods/ { 代理 请 求 到 Pod 
name}/proxy 
orm | (apilv namespaces! {namespace}pods!{ | 12 99 OPTIONS if RIM Pod 
name} /proxy 
Japi'v Li j. 
apy inamesaces/{namespace)podsi{’ | 代理 POST 请 求 到 Pod 
name}/proxy 


fapv $ j 
api'v l/namespaces/ {namespace }/pods/ { 代理 PUT 请 求 到 Pod 
name}/proxy 
peters fapi/vl/proxy/namespaces/{namespace}/ | 代理 DELETE 请 求 到 Pod 的 某 个 子 


pods/ {name}/ {path:*} 目录 


/apv'v1/proxy/namespaces/ {namespace}! ea ari 


/api/v1/proxy/mamespaces/{namespace}/ | 代理 HEAD 请 求 到 pod HATA 
pods/{name}/{path:*} 录 


pods/{name}/{path:*} FAR 


post | spit Mproxyinamespaces/{namespace}/ | 代理 POST 请 求 到 Pod NIAT H 
pods! {name}/{path:*} x 


续 表 
站 


14 ces/ : 

/api'vl /proxy/namespaces/ {namespace} 代理 PUT 请 求 到 Pod 的 某 个 子 目录 
po | ee +} 

vl f ! 

api/vl/proxy/namespaces/ {namespace}! 代理 DELETE 请 求 到 Pod 
fer [in 
/apiivl. ces/ l 
fapivfproxyinamespaces/{namespace}! | 代理 GET 请 求 到 Pod 
Ee 
fapi'v1/ J 
pole) 


ivl riname namesp 
rise co Saat i = E 
en | {name} 


/api'v1/proxy/namespaces/ {namespace} / 
pods/ {name} 


代理 POST 请 求 到 Pod 


/api'v 1 /proxy/namespaces/ {namespace}/ 
wr | {name} 


代理 PUT 请 求 到 Pod 


监听 所 有 Endpoint 的 变化 


GET 
Enn /apu'vl/watch/namespaces!{namespace}/ | {i W 某 个 Namespace 下 所 有 
ENDPOINTS WATCH endpoints Endpoint 的 变化 


/apivl/watch s] s! { 
endpoints/ {name} 


监听 所 有 Service Account 的 变化 
fapi/vl/watch/ J i i 某 j 
PORTE cn api/vl/watch/namespaces/ {namespace} 监听 某 个 Namespace 下 所 有 
WATCH serviceaccounts ServiceAccount 的 变化 
lapi'v l/watch/namespaces/ {namespace} / 
GET = | ea 
serviceaccounts/ {name} 


= 监听 所 有 Secret 的 变化 
/api'v1/watch/‘namespaces/ {namespace} / et ; 个 Namespace 下 所 有 Secret 
SECRET WATCH 
secrets/ {name} 


监听 所 有 Event 的 变化 
EVENTS WATCH 


a /api'vl /watch/namespaces/{mamespace}/ | 监听 某 个 Namespace 下 所 有 Event 
events 的 变化 





续 表 
资源 类 型 | 类 别 | 方 法 | unre | 说明 O 
‘api'v1/watch/namespaces! {namespace}/ 监听 某 个 Event 的 变化 
events’ {name} 


api watch limitranges 

‘api'v1/watch/namespaces/{mamespace}/ | 蓝 昕 某 个 Namespace 下 所 有 Event 
LIMITRANGES | WATCH limitranges 的 变化 

lapi/vl/watch/namespaces/ {namespace}/ 


监听 某 个 Event 的 变化 


limitranges/ {name} 


a IRMA ResourceQuora 的 变化 


/api'v1/watch‘namespaces/{mamespace}/ | H Wy M A Namespace 下 所 有 
WATCH resourcequotas ResourceQuota 的 变化 


/apv'v1/watch/‘namespaces! {mamespace}/ 


= 


监听 某 个 ResourceQuota 的 变化 


= eee {name} 


Fg lapi'vl/watch/podtemplates 监听 所 有 PodTemplate 的 变化 


‘api'v1/watch‘namespaces/{namespace}/ | 监 昕 某 个 Namespace 下 所 有 
PODTEMPLATES | WATCH = PodTemplate 的 变化 


‘api/v1/watch/‘namespaces/ {namespace} / 


WAFS PodTemplate 的 变化 
m | ee {name} 


PERSISTENTV AR /apv'v1/watch/persistentvolumes HUH PersistentVolume 的 变化 
OLUMES /apv'v1/watch'persistentvolumes/{name} | 监听 某 个 PersistentVolume 的 变化 


监听 所 有 PersistentVolumeClaim 的 
/apv'v 1 /watch’persistentvolumeclaims tik 


PERSISTENTV lanes ‘apv/'v1/watch/namespaces/{mamespace}/ | {fi Wy M “+ Namespace 下 所 有 
OLUMECLAIMS persistentvolumeclaims PersistentVolumeClaim 的 变化 
‘apv'v1/watch/namespaces/ {namespace} / 监听 某 个 PersistentVolumeClaim 的 


persistentvolumeclaims/ {name} 变化 





下 面 基 于 Fabric8 实 现 对 资源 对 象 的 监听 〈Watch) ， 代 码 如 下 : 


privatevoid testWatcher() { 
_kube.pods().watch(new io.fabric8.kubernetes.. 
@Override 
publicvoid eventReceived(Action action, Pod pod) { 


System.out.printlin(action + ": " + pod); 


@Override 


publicvoid onClose(KubernetesClientException e) { 


System.out.printin("Closed: " + e); 


}); 


接 下 来 基于 Jersey 框 架 实 现 通 过 Proxy 方 式 访 问 Pod。 由 于 API Server 
针对 Pod 资 源 提供 了 两 种 Proxy 访 问 接 口 ， 所 以 下 面 分 别 用 两 段 代码 进行 
示例 说 明 。 代 码 如 下 : 


privatevoid testPoxyPod() { 
// 访 问 第 1 种 proxy 接 口 
Params params = new Params(); 
params.setNamespace("ns-sample"); 
params.setName("pod-sample-in-namespace"); 
params.setSubPath("/proxy"); 


params.setResourceType(ResourceType.PODS) ; 


_restfulClient.get(params); 

// 访 问 第 2 种 proxy 接 口 

params = new Params(); 
params.setNamespace("ns-sample"); 
params.setName("pod-sample-in-namespace"); 
params.setVisitProxy(true); 


params.setResourceType(ResourceType.PODS) ; 


_restfulClient.get(params) ) ， 


第 5 瘟 ”Kubernetes 运 维 指 两 


为 了 让 容器 应 用 在 Kubernetes 集 群 中 运行 得 更 加 有 效 ， 对 Kubernetes 
集群 本 身 也 需要 进行 相应 的 配置 和 管理 。 本 章 将 从 Kubernetes 集 群 管 
理 、 高 级 案例 及 Trouble Shooting 等 方面 对 Kubernetes 集 群 的 运 维和 查 错 
进行 详细 说 明 ， 最 后 对 Kubernetes1.3 版 本 开发 中 的 新 功能 进行 介绍 。 


5.1 Kubernetes 集 群 管理 指南 


本 节 将 从 Node 的 管理 、Label 的 管理 、Namespace 资 源 共 享 、 资 源 配 
额 管理 、 集 群 Master 高 可 用 及 集群 监控 等 方面 ， 对 Kubernetes 集 群 本 身 
的 运 维 管理 进行 详细 说 明 。 


5.1.1 Node 的 管理 


1.Node 的 隔离 与 恢复 


在 便 件 升级 、 硬 件 维护 等 情况 下 ， 我 们 需要 将 某 些 Node 进 行 隔离 ， 
脱离 Kubernetes 集 群 的 调度 范围 。Kubernetes 提 供 了 一 种 机 制 ， 既 可 以 将 
Node 纳 入 调度 范围 ， 也 可 以 将 Node 脱 离 调 度 范 围 。 


创建 配置 文件 unschedule_node.yaml， 在 spec 部 分 指定 unschedulable 
为 true: 


apiVersion: v1 
kind: Node 
metadata: 
name: k8s-node-1 
labels: 
kubernetes.io/hostname: k8s-node-1 
spec: 


unschedulable: true 


然后 ， 通 过 kubectl replace 命 令 完 成 对 Node 状 态 的 修改 : 


$ kubectl replace -f unschedule_node.yaml 


node "k8s-node-1" replaced 





查看 Node 的 状态 ， 可 以 观察 到 在 Node 的 状态 中 增加 了 一 项 
SchedulingDisabled: 


# kubectl get nodes 
NAME STATUS AGE 
k8s-node-1 Ready, SchedulingDisabled 1h 


对 于 后 续 创 建 的 Pod， 系 统 将 不 会 再 向 该 Node 进 行 调度 。 





也 可 以 不 使 用 配置 文件 ， 直 接 使 用 kubectl patch 命 令 完成 : 


$ kubectl patch node k8s-node-1 -p '{"spec":{"unschedula 





需要 注意 的 是 ， 将 东 个 Node 脱 离 调 度 范围 时 ， 在 其 上 运行 的 Pod 并 
不 会 目 动 停止 ， 管 理 员 需要 手动 停止 在 该 Node 上 运行 的 Pod。 











同样 ， 如 果 需 要 将 某 个 Node 重 新 纳入 集群 调度 范围 ， 则 将 
unschedulable 设 置 为 false， 再 次 执行 kubectl replace 或 kubectl patch + wt 
能 恢复 系统 对 该 Node 的 调度 。 


在 Kubernetes 当 前 的 版 本 中 ，kubectl 的 子 命令 cordon 和 uncordon 也 用 
于 实现 将 Node 进 行 隔离 和 恢复 调度 的 操作 。 





例如 ， 使 用 kubectl cordon<node_name> 对 某 个 Node 进 行 隔离 调度 操 
作 : 


# kubectl cordon k8s-node-1 


node "k8s-node-1" cordoned 


# kubectl get nodes 
NAME STATUS AGE 
k8s-node-1 Ready, SchedulingDisabled ih 

使 用 kubectl uncordon 


使 用 kubectl uncordon<node_name> 对 某 个 Node 进 行 恢复 调度 操作 : 


# kubectl uncordon k8s-node-1 


node "k8s-node-1" uncordoned 


# kubectl get nodes 


NAME STATUS AGE 
k8s-node-1 Ready 1h 
2.Node 的 扩容 


在 实际 生产 系统 中 会 经 遇 到 服务 器 容量 不 足 的 情况 ， 这 时 惑 需要 
购买 新 的 服务 器 ， 然 后 将 应 用 系统 进行 水 平 扩展 来 完成 对 系统 的 扩容 。 








在 Kubernetes 集 群 中 ， 一 个 新 Node 的 加 入 是 非常 简单 的 。 在 新 的 
Node 节 点 上 安装 Docker、kubelet 和 kube-proxy 服 务 ， 然 后 配置 kubelet 和 
kube-proxy 的 启动 参数 ， 将 Master URL 指 定 为 当前 Kubernetes 集 群 Master 
的 地 址 ， 最 后 启动 这 些 服务 。 通 过 kubelet 默 认 的 自动 注册 机 制 ， 新 的 
Node 将 会 自动 加 入 现 有 的 Kubernetes 集 群 中 ， 如 图 5.1 所 示 。 
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图 5.1 新 节点 目 动 注册 完成 扩容 


Kubernetes _ Master 在 接受 了 新 Node 的 注册 之 后 ， 会 自动 将 其 纳入 当 
前 集群 的 调度 范围 内 ， 在 之 后 创建 容器 时 ， 就 可 以 问 新 的 Node 进 行 调度 
Tg 


通过 这 种 机 制 ，Kubernetes 实 现 了 集群 中 Node 的 扩容 。 


5.1.2 ”更 新 资源 对 象 的 Label 


Label (标签 DPI) ATC NaI 在 正在 运行 的 资 
源 对 象 上 ， 仍 然 可 以 随时 通过 kubectl label 命 令 对 其 进行 增加 、 修 改 、 删 
除 等 操作 。 


例如 ， 我 们 要 给 已 创建 的 Pod“redis-master-bobr0? 添 加 一 个 标签 


role=backend: 


$ kubectl label pod redis-master-bobr0 role=backend 


pod "redis-master-bobr0" labeled 


查看 该 Pod 的 Label: 


$ kubectl get pods -Lrole 
NAME READY STATUS RESTARTS AGE 


redis-master -bobr0 1/1 Running 0 3m 


删除 一 个 Label 时 ， 只 需 在 命令 行 最 后 指定 Label 的 key 名 并 与 一 个 减 
号 相连 即 可 : 


$ kubectl label pod redis-master-bobrO role- 


pod "redis-master-bobr0" labeled 


修改 一 个 Label 的 值 时 ， 需 要 加 上 --overwrite 参 数 : 


$ kubectl label pod redis-master-bobr® role=master --ove 


pod "redis-master-bobr0" labeled 


5.1.3 Namespace: 集群 环境 共享 与 隔离 


在 一 个 组 织 内 部 ， 不 同 的 工作 组 可 以 在 同一 个 Kubernetes 集 群 中 工 
作 ，Kubernetes 通 过 命名 空间 和 Context 的 设置 来 对 不 同 的 工作 组 进行 区 
分 ， 使 得 它们 既 可 以 共享 同一 个 Kubernetes 集 群 的 服务 ， 也 能 够 互 不 干 
扰 ， 如 图 5.2 所 示 。 





图 5.2 集群 环境 共享 和 隔离 





假设 在 我 们 的 组 织 中 有 两 个 工作 组 : 开发 组 和 生产 运 维 组 。 开 发 组 
在 Kubernetes 集 群 中 需要 不 断 创 建 、 修 改 、 删 除 各 种 Pod、RC、 Service 
等 资源 对 象 ， 以 便 实 现 敏 捷 开 发 的 过 程 。 而 生产 运 维 组 则 需要 使 用 严格 
的 权限 设置 来 确保 生产 系统 中 的 Pod、RC、Service 处 于 正常 运行 状态 且 
不 会 被 误 操 作 。 


1. 创 建 namespace 


为 了 在 Kubernetes 集 群 中 实现 这 两 个 分 组 ， 首 先 需要 创建 两 个 命名 


ale 
namespace-development.yaml: 


apiversion: v1 
kind: Namespace 
metadata: 


name: development 


namespace-production.yaml: 


apivVersion: vi 
kind: Namespace 
metadata: 


name: production 


使 用 kubectl create 命 令 完 成 命名 空间 的 创建 : 


$ kubectl create -f namespace-development.yaml 


namespaces/development 


$ kubectl create -f namespace-production.yaml 


namespaces/production 


查看 系统 中 的 命名 空间 : 


$ kubectl get namespaces 


NAME LABELS STATUS 
default <none> Active 
development name=development Active 


production name=production Active 


2. 定 义 Context (运行 环境 ) 


接 下 来 ， 需 要 为 这 两 个 工作 组 分 别 定义 一 个 Context， 即 运行 环境 。 
这 个 运行 环境 将 属于 某 个 特定 的 命名 空间 。 





通过 kubectl config set-context 命 令 定 义 Context， 并 将 Context 置 于 之 
前 创建 的 命名 空间 中 : 


$ kubectl config set-cluster kubernetes-cluster --server: 
$ kubectl config set-context ctx-dev --namespace=develop! 


$ kubectl config set-context ctx-prod --namespace=produc 


使 用 kubectl config view 命 令 查 看 已 定义 的 Context: 


$ kubectl config view 
apiversion: vi 
clusters: 
- cluster: 
server: http://192.168.1.128:8080 
name: kubernetes-cluster 
contexts: 


- context: 


cluster: kubernetes-cluster 
namespace: development 
name: ctx-dev 
- context: 
cluster: kubernetes-cluster 
namespace: production 
name: ctx-prod 
current-context: ctx-dev 
kind: Config 
preferences: {} 


users: [] 


注意 ， 通 过 kubectl config 命 令 在 ${HOME}.kube 目 录 下 生成 了 一 个 
名 为 config 的 文件 ， 文 件 内 容 即 以 kubectl config ” ”view 命令 查看 到 的 内 
容 。 所 以 ， 也 可 以 通过 手工 编辑 该 文件 的 方式 来 设置 Context。 

3. 设 置 工作 组 在 特定 Context 环 境 中 工作 


使 用 kubectl config use-context<context_name> 命 令 来 设置 当前 的 运 
行 环境 。 


下 面 的 命令 将 把 当前 运行 环境 设置 为 “ctx-dev”: 


$ kubectl config use-context ctx-dev 


通过 这 个 命令 ， 当 前 的 运行 环境 即 被 设置 为 开发 组 所 需 的 环境 。 之 
后 的 所 有 操作 都 将 在 名 为 “development”* 的 命名 空间 中 完成 。 


现在 ， 以 redis-slave RC 为 例 创 建 两 个 Pod: 


redis-slave-controller.yaml 


apiVersion: v1 
kind: ReplicationController 
metadata: 
name: redis-slave 
labels: 
name: redis-slave 
spec: 
replicas: 2 
selector: 
name: redis-slave 
template: 
metadata: 
labels: 
name: redis-slave 
spec: 
containers: 
- name: slave 
image: kubeguide/guestbook-redis-slave 
ports: 


- containerPort: 6379 


$ kubectl create -f redis-slave-controller.yaml 


replicationcontrollers/redis-slave 


查看 创建 好 的 Pod: 


$ kubectl get pods 


NAME READY STATUS RESTARTS 
redis-slave-0feq9 1/1 Running 0 
redis-slave-610g4 1/1 Running 0 


可 以 看 到 容器 被 正确 创建 并 运行 起 来 了 。 而 且 ， 由 于 当前 的 运行 环 
境 是 ctx-dev， 所 以 不 会 影响 到 生产 运 维 组 的 工作 。 


让 我 们 切换 到 生产 运 维 组 的 运行 环境 : 
$ kubectl config use-context ctx-prod 
查看 RC 和 Pod: 


$ kubectl get rc 


CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLIC, 


$ kubectl get pods 


NAME READY STATUS RESTARTS AGE 
结果 为 空 ， 说 明 看 不 到 开发 组 创建 的 RC 和 Pod。 
现在 我 们 为 生产 运 维 组 也 创建 两 个 redis-slave 的 Pod: 


$ kubectl create -f redis-slave-controller.yaml 


replicationcontrollers/redis-slave 


查看 创建 好 的 Pod: 


$ kubectl get pods 


NAME READY STATUS RESTARTS AGE 
redis-slave-a4m7s 1/1 Running 0 12s 
redis-slave-xyrkk 1/1 Running 0 12s 


可 以 看 到 容器 被 正确 创建 并 运行 起 来 了 ， 并 且 当 前 的 运行 环境 是 
ctx-prod， 也 不 会 影响 开发 组 的 工作 。 





至 此 ， 我 们 为 两 个 工作 组 分 别 设置 了 两 个 运行 环境 ， 在 设置 好 当前 
的 运行 环境 时 ， 各 工作 组 之 间 的 工作 将 不 会 相互 和 干扰， 并且 它们 都 能 够 
在 同一 个 Kubernetes 集 群 中 同时 工作 。 


5.1.4 Kubernetes 资 源 管理 


本 章 从 计算 资源 管理 (Compute Resources) 、 资 源 配 置 范围 管理 
(LimitRange) 、 服 务 质量 管理 (QoS) 及 资源 配额 管理 
(ResourceQuota) 等 方面 ， 对 Kubernetes 和 集群 内 的 资源 管理 进行 详细 说 
明 ， 结 合 实践 操作 、 常 见 问 题 分 析 和 一 个 完整 的 示例 ， 对 Kubernetes 集 
群 资源 管理 相关 的 运 维 工 作 提 供 指 导 。 


1. 计 算 资 源 管理 (Compute Resources) 


在 配置 Pod 的 时 候 ， 我 们 可 以 为 其 中 的 每 个 容器 指定 需要 使 用 的 计 
算 资 源 (CPU 和 内 存 ) 。 


计算 资源 的 配置 项 分 为 两 种 : 一 种 是 资源 请 求 〈(Resource 
Reduests， 人 简称 Requests) ， 表 示 容 器 希望 被 分 配 到 的 、 可 完全 保证 的 
资源 量 ，Requests 的 值 会 提供 给 Kubernetes 调 度 器 (Kubernetes 
Scheduler) 以 便于 优化 基于 资源 请 求 的 容器 调度 ; 另外 一 种 是 资源 限制 
(Resource Limits， 简 称 Limits〉，Limits 是 容器 最 多 能 使 用 到 的 资源 量 
的 上 限 ， 这 个 上 限 值 会 影响 节点 上 发 生 资 源 苑 争 时 的 解决 策略 。 











当前 版 本 的 Kubernetes 中 ， 计 算 资 源 的 资源 类 型 分 为 两 种 : CPU 和 
内 存 (Memory) 。 这 两 种 资源 类 型 都 有 一 个 基本 单位 : 对 于 CPU 而 
言 ， 基 本 单位 是 核心 数 (Cores) ; 而 内 存 的 基本 单位 是 字 节 数 
(Bytes) 。CPU 和 内 存 一 起 构成 了 目前 Kubernetes 中 的 计算 资源 〈 也 可 
简称 为 资源 ) 。 








计算 资源 是 可 计量 的 ， 能 被 申请 、 分 配 和 使 用 的 基础 资源 ， 这 使 之 
区 别 于 API 资 源 (API Resources， 例 如 Pod 和 services 等 ) 。 


1) Pod 和 容器 的 Requests 和 Limits 
Pod 中 的 每 个 容器 都 可 以 配置 以 下 4 个 参数 。 


e spec.container[].resources.requests.cpu. 
e spec.container[].resources.limits.cpu. 
e spec.container[].resources.requests.memory. 


e spec.container|].resources.limits.memory » 


这 四 个 参数 分 别 对 应 容器 的 CPU 和 内 存 的 Requests 和 Limits， 它 们 具 
有 以 下 特点 。 


。 Requests 和 Limits 都 是 可 选 的 。 在 某 些 集群 中 如 果 在 Pod 创 建 或 者 更 
新 的 时 候 ， 0 A R: 那么 可 能 会 使 用 系统 
提供 一 个 默认 值 ， 这 个 默认 值 取决 于 集群 的 配置 。 

。 如 果 Request 没 有 配置 ， 那 么 默认 会 被 设置 为 等 于 Limits。 

。 而 任何 情况 下 Limits 都 应 该 设置 为 大 于 或 者 等 于 Requests。 





以 CPU 为 例 ， 图 5.3 显 示 了 未 设置 CPU Limits 和 设置 CPU Limits 的 
CPU 使 用 率 的 区 别 。 


未 设置 CPU Limits 的 CPU 使 用 率 设置 了 CPU Requests 和 CPU Limits 
的 CPU 使 用 率 


CPU Limits: 0.8 C 





CPU Requests: 0.2 C 





图 5.3 未 设置 和 设置 了 CPU Limits 的 CPU 使 用 率 样 例 


尽管 Requests 和 Limits 只 能 设置 到 容器 上 ， 但 是 设置 Pod 级 别 的 
Requests 和 Limits 能 极 大 程度 上 提高 我 们 对 Pod 管 理 的 便利 性 和 有 灵活 性 ， 
因此 Kubernetes 中 提供 对 Pod 级 别 的 Requests 和 Limits 配 置 。 对 于 CPU 和 
内 存 而 言 ，Pod 的 Requests 或 Limits 是 指 该 Pod 中 所 有 容器 的 Requests 或 
Limits AA 〈 了 Pod 中 没 设置 Request 或 Limits 的 容器 ， 该 项 的 值 被 当 作 0 
或 者 按照 集群 配置 的 默认 值 来 计算 ) 。 下 面 对 CPU 和 内 存 这 两 种 计算 资 
源 各 自 的 特点 进行 说 明 。 








(1) CPU 


CPU 的 Requests 和 Limits 是 通过 CPU 数 (cpus) 来 度量 的 。CPU 资 源 
值 文 持 最 多 三 位 小 数 : 如 果 一 个 容器 的 
spec.container[].resources.requests.cpu 设 置 为 0.5， 那 么 它 会 获得 半 个 
CPU; 同 理 如 采 设 置 为 1， 就 会 获得 1 个 CPU。0.1CPU 等 价 于 100m 
CPU (100millicpu) ， 而 在 Kubernetes API 中 自动 将 这 种 小 数 0.1 转 化 为 
100m， 因 此 CPU 的 小 数 最 多 文 持 三 位 数字 ， 而 Kubernetes 官 方 也 更 推荐 
直接 使 用 形 如 100m 的 millicpu 作 为 计量 单位 。 





CPU 资源 值 是 绝对 值 ， 而 不 是 相对 值 : 比如 0.1CPU 不 管 是 在 单 核 或 
者 多 核 机 器 上 都 是 一 样 的 ， 都 严格 等 于 0.1CPU core. 


(2) 内 存 (Memory) 





内 存 的 Requests 和 Limits 计 量 单位 是 字 节 数 (Bytes) 。 内 存 值 用 使 
用 整数 或 者 定点 整数 加 上 国际 单位 制 (International System of Units) 来 
表示 。 国 际 单位 制 包括 十 进 制 的 E、P、T、G、M、K、m,， 或 二 进 制 的 
Fi、Pi、Ti、Gi、Mi、Ki。 比 如 : KiB 与 MiB 是 二 进 制 表 示 的 字 节 单 


位 ， 而 常见 的 KB 与 MB 则 是 十 进 制 表 示 的 字 市 单位 。 两 种 方式 的 区 别 举 
例 说 明 如 下 : 


1KB (kilobyte) =1000bytes=8000bits 


1KiB (kibibyte) =2^10bytes=1024bytes=8192bits 











因此 ， 下 面 几 种 内 存 配 置 的 意思 是 一 样 的 :128974848、129e6、 
129M、123Mi 





Kubernetes 的 计算 资源 单位 是 大 小 写 敏感 的 ， 因 为 m 可 以 表示 干 分 
之 一 单位 mili unit) ， 而 M 可 以 表示 十 进 制 的 1000， 两 者 的 含义 不 
同 ;， 同 理 可 知 ， 小 写 的 k 不 是 一 个 合法 的 资源 单位 。 





以 一 个 Pod 中 的 资源 配置 为 例 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: frontend 
spec: 
containers: 
- name: db 
image: mysql 
resources: 
requests: 
memory: "64Mi" 
cpu: "250m" 


limits: 


memory: "128Mi" 
cpu: "500m" 
- name: wp 
image: wordpress 
resources: 
requests: 
memory: "64Mi" 
cpu: "250m" 
limits: 
memory: "128Mi" 


cpu: "500m" 


该 Pod 包 含 两 个 容器 ， 每 个 容器 配置 的 Requests 都 是 0.25CPU 和 
64MiB (2^6bytes 内 存 ， 而 配置 的 Limits 都 是 0.5CPU 和 
128MiB (22/bytes) 内 存 。 


这 个 Pod 的 Requests 和 Limits 等 于 Pod 中 所 有 容器 对 应 配置 的 总 和 ， 
所 以 Pod 的 Requests 是 0.5CPU 和 128MiB (22/bytes) 内 存 ，Limits 是 
1CPU 和 256MiB (228bytes〉 内 存 。 


2) 基于 Requests 和 Limits 的 Pod 调 度 机 制 


当 一 个 Pod 创 建成 功 时 ，Kubernetes 调 度 器 〈Scheduler) 为 该 Pod 选 
择 一 个 节点 (Node) 来 执行 。 对 于 每 种 计算 资源 (CPU 和 内 存 〉 而 言 ， 
每 个 节点 都 有 一 个 能 用 于 运行 Pod 的 最 大 容量 值 。 调 度 器 在 调度 时 ， 首 
先 要 确保 调度 后 该 节点 上 所 有 Pod 的 CPU 和 内 存 的 Requests 总 和 不 能 超过 
该 节点 能 提供 给 Pod 使 用 的 CPU 和 内 存 的 最 大 容量 值 。 











例如 某 个 节点 上 CPU 资源 充足 ， 而 内 存 为 4GB， 其 中 3GB 可 以 运行 
Pod， 某 Pod 的 内 存 Requests 为 1GB、Limits 为 2GB， 那 么 这 个 节点 上 最 多 
可 运行 3 个 这 种 Pod。 








这 里 需要 注意 的 是 : 可 能 某 些 节点 上 的 实际 资源 使 用 量 非常 低 ， 但 
是 如 果 该 节点 上 已 运行 Pod 配 置 的 Requests 值 的 总 和 已 经 非常 高 ， 再 加 上 
需要 调度 的 Pod 的 Requests 值 会 直接 超过 该 节点 提供 给 Pod 的 资源 容量 上 
限 ，Kubernetes 仍 然 不 会 将 Pod 调 度 到 这 个 节点 上 。 这 是 因为 如 果 
Kubernetes 将 Pod 调 度 到 该 节点 上 ， 那 么 如 果 后 面 该 节点 上 运行 的 Pod 面 
临 服务 峰值 等 情况 ， 可 能 会 导致 Pod 资 源 短缺 的 情况 发 生 。 





接着 上 面 的 例子 ， 假 设 该 节点 已 经 启动 3 个 Pod 实 例 ， 而 这 3 个 Pod 的 
实际 内 存 使 用 都 不 足 500MB， 那 么 理论 上 该 节点 的 可 用 内 存 应 该 大 于 
1.5GB， 但 是 由 于 该 节点 的 Pod Requests 总 和 已 经 等 于 节点 的 可 用 内 存 上 
限 ， 因 此 Kubernetes 不 会 再 将 任何 Pod 实 例 调度 到 该 节点 上 执行 。 





3) Requests 和 Limits 资 源 配 置 机 制 


当 kubelet 启 动 Pod 的 一 个 容器 时 ， 它 会 将 容 右 的 Requests 和 Limits 值 
转化 为 相应 的 容器 启动 参数 传递 给 容器 执行 器 (Docker 或 者 是 rkt) 。 





如 果 容 器 的 执行 环境 是 Docker， 那 么 容器 的 4 个 参数 是 这 样 传递 给 
Docker 的 。 


(1) spec.container[].resources.requests.cpu 


这 个 参数 会 转化 为 core 数 〈 比 如 配置 的 100m 会 转化 为 0.1) ， 然 后 
乘 以 1024， 再 将 这 个 结果 作为 --cpu-shares 参 数 的 值 传递 给 docker ”run 命 
令 。 在 docker ”run 命令 中 ，--cpu-share 参 数 是 一 个 相对 权重 值 (Relative 


Weight) ， 这 个 相对 权重 值 会 决定 Docker 在 资源 竞争 时 分 配给 容器 的 资 
源 比例 。 举 例 说 明 --cpu-shares 参 数 在 Docker 中 的 含义 : 比如 两 个 容器 的 
CPU Requests 分 别 设置 为 /和 2， 那 么 容器 在 docker run 启 动 时 对 应 的 -- 
cpu-shares 参 数值 分 别 为 1024 和 2048， 在 主机 CPU 资源 产生 竞争 时 ， 
Docker 会 答 试 按照 1 : 2 的 配 比 将 CPU 资源 分 配给 这 两 个 容器 使 用 。 





这 里 需要 区 分 清楚 的 是 : 这 个 参数 对 于 Kubernetes 而 言 是 绝对 值 ， 
主要 用 于 Kubernetes 调 度 和 管理 的 依据 《参见 下 文 QoS 章节 ) ; 同时 这 
个 参数 值 会 设置 为 --cpu-shares 参 数 传 递 给 Docker，--cpu-shares 参 数 对 于 
Docker 而 言 又 是 相对 值 ， 主 要 用 于 资源 分 配 比 例 。 这 两 种 用 途 的 作用 范 
围 不 同 ， 所 以 并 不 会 及 生 冲 突 。 


(2) spec.container[].resources.limits.cpu 


这 个 参数 会 转化 为 millicore 数 “比如 配置 的 1 会 转化 为 1000， 而 配置 
的 100m 转 化 为 100) ， 将 此 值 乘 以 100000， 再 除 以 1000， 然 后 将 结果 值 
作为 --<cpu-quota 参 数 的 值 传递 给 docker run 命 令 。docker run 命 令 中 另外 
一 个 参数 --cpu-period 默 认 设 置 为 100000， 表 示 Docker 重 新 计量 和 分 配 
CPU 的 使 用 时 间 间 隔 为 100000 微 秒 〈100 毫 秒 ) 。 


Docker 的 --cpu-quota 参 数 和 --cpu-period 参 数 一 起 配合 完成 对 容器 
CPU 的 使 用 限制 : 比如 Kubernetes 中 配置 容器 的 CPU Limits 为 0.1， 那 么 
计算 后 --cpu-quota 为 10000， 而 --cpu-period 为 100000， 这 意味 着 Docker 在 
100 毫 秒 内 最 多 给 该 容器 分 配 10 毫 秒 *core 的 计算 资源 用 量 ， 
10/100=0.1core 的 结果 与 Kubernetes 配 置 的 意义 是 一 致 的 。 





JER: 如 果 kubelet 启 动 参数 --cpu-cfs-quota 设 置 为 tue， 那 么 kubelet 
会 强制 要 求 所 有 Pod 都 必须 配置 CPU Limits (如 果 Pod 没 配置 ， 而 集群 提 


供 了 默认 配置 也 可 以 ) 。 而 从 Kubernetes ”1.2 版 本 开始 ， 这 个 --cpu-cfs- 
quota 启 动 参数 的 默认 值 就 是 true。 


(3) spec.container[].resources.requests.memory 


这 个 参数 值 只 提供 给 Kubernetes 调 度 器 (Kubernetes Scheduler) 作 
为 调度 和 管理 的 依据 ， 不 会 作为 任何 参数 传递 给 Docker。 


(4) spec.container[].resources.limits.memory 


这 个 参数 值 会 转化 为 单位 为 bytes 的 整数 ， 数 值 会 作为 -memory 参 数 


传递 给 docker run 命 令 。 


如 果 一 个 容 需 在 运行 过 程 中 使 用 了 超出 了 其 内 存 Limits 配 置 的 内 存 
IRENE, AKA EY BESS AT”, MRANA ee PY Bi FS A a 
那么 之 后 它 会 被 kubelet 重 新 局 动 起 来 。 因 此 容器 的 Limits 配 置 需 要 进行 
准确 的 测试 和 评估 。 





与 内 存 Limits 不 同 的 是 CPU 在 容器 技术 中 属于 可 压缩 资源 ， 因 此 对 
于 CPU 的 Limits 配 置 一 般 不 会 引发 因 偶然 超标 使 用 而 导致 容器 被 系统 < 杀 
掉 * 的 情况 。 


4) 计算 资源 使 用 情况 监控 


Pod 的 资源 用 量 会 作为 Pod 的 状态 信息 一 同上 报 给 Master。 如 果 集 群 
中 配置 了 Heapster 来 监控 集群 的 性 能 数据 ， 那 么 还 可 以 从 Heapster 中 查看 
Pod 的 资源 用 量 信 息 。 


5) 计算 资源 相关 常见 问题 分 析 


(1) Pod 状 态 为 pending， 错 误 信息 为 FailedScheduling。 


如 果 Kubernetes 调 度 器 (Kubernetes Scheduler) 在 集群 中 找 不 到 合 
适 的 节点 来 运行 Pod， 那 么 这 个 Pod 会 一 直 处 于 未 调度 状态 ， 直 到 调度 器 
找到 合适 的 节点 为 止 。 每 次 调度 器 尝试 调度 失败 ，Kubernetes 都 会 产生 
一 个 事件 Cevent) ， 我 们 可 以 通过 下 面 这 种 方式 来 查看 事件 的 信息 : 

















$ kubectl describe pod frontend | grep -A 3 Events 


Events: 
FirstSeen LastSeen Count From Sub 
36S 5s 6 {schedule 


在 上 面 这 个 例子 中 ， 名 为 frontend 的 Pod 由 于 节点 的 CPU 资源 不 足 而 
调度 失败 (PodExceedsFreeCPU) ， 同 样 ， 如 果 内 存 不 足 也 可 能 导致 调 
度 失 败 (PodExceedsFreeMemory) 。 





如 有 果 一 个 或 者 多 个 Pod 调 度 失败 且 有 这 类 错误 ， 那 么 我 们 可 以 尝试 
以 下 几 种 解决 方法 。 
。 添加 更 多 的 节点 到 集群 中 。 
。 停止 一 些 不 必要 的 运行 中 的 Pod， 释 放 资 源 。 
。 检查 Pod 的 配置 ， 错 误 的 配置 可 能 导致 该 Pod 永 远 都 无 法 被 调度 执 
行 。 比 如 如 果 整 个 集群 中 所 有 市 点 都 只 有 1CPU， 而 Pod 配 置 的 CPU 
Requests 为 2， 那 么 该 Pod 就 不 会 被 调度 执行 。 











我 们 可 以 使 用 kubectl describe nodes 命 令 来 查看 集群 中 节点 的 计算 资 
源 容量 和 已 使 用 量 : 


$ kubectl describe nodes k8s-node-1 


Name: k8s-node-1 


Capacity: 
Cpu: 1 
memory: 464M1 
pods: 40 
Allocated resources (total requests): 
Cpu: 910m 


memory: 2370Mi 


pods: 4 

Pods: (4 in total) 
Namespace Name 
frontend webserver -ffj8j 
kube-system fluentd-cloud-logging 
kube-system kube-dns-v8-qopgw 


TotalResourceLimits: 
CPU(milliCPU): 910 (91% of total) 
Memory(bytes): 2485125120 (59% of total) 





超过 可 用 资源 容量 上 限 〈Capacity) 和 已 分 配 资源 量 (Allocated 
resources) 差额 的 Pod 无 法 运行 在 该 Node 上 。 这 个 例子 中 ， 如 果 一 个 Pod 
的 Requests 超 过 90millicpus 或 者 超过 1341MiB 内 存 ， 那 么 就 无 法 运行 在 这 
Aie 
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在 后 面 的 资源 配额 (Resource Quota) 章节 中 ， 我 们 还 可 以 配置 针 
对 一 组 Pod 的 Requests 和 Limits 总 量 的 限制 ， 这 种 限制 可 以 作用 于 命名 空 
间 ， 通 过 这 种 方式 我 们 可 以 防止 一 个 命名 空间 下 的 用 户 将 所 有 资源 全 部 
HAA - 


(2) REBIT IE (Terminated) 


如 有 果 容 器 使 用 的 资 ee ni 那么 该 容器 可 能 Ri 
强制 终止 。 我 们 可 以 通过 kubectl describe pod 命 令 来 确认 容器 是 否 是 
为 这 个 原因 被 终止 的 : 


$ kubectl describe pod simmemleak-hra99 


Name: simmemleak -hra99Q 
Namespace: default 
Image(s): saadali/simmemleak 
Node: 192.168.18.3 
Labels: name=simmemleak 
Status: Running 
Reason: 
Message: 
IP: 172.17.1.3 
Replication Controllers: Simmemleak (1/1 replicas 
Containers: 

simmemleak: 


Image: saadali/simmemleak 
Limits: 


cpu: 100m 


memory : 
State : 


Started: 


Last Termination State: 


Exit Code: 

Started: 

Finished: 
Ready: 


Restart Count: 


Conditions: 
Type Status 
Ready False 
Events: 
FirstSeen 


Tue, 07 Jul 2015 
Tue, 07 Jul 2015 
Tue, 07 Jul 2015 
Tue, 07 Jul 2015 
Tue, O07 Jul 2015 


12:53: 
12:53: 
12:53: 
12:53: 
12:53: 


51 
51 
51 
51 
51 


50Mi 

Running 

Tue, 07 Jul 2015 12:54:4 
Terminated 

1 

Fri, 07 Jul 2015 12:54:3 
Fri, 07 Jul 2015 12:54:3 
False 


5 


LastSeen 
-0700 Tue, O07 Jul 2015 12: 
-0700 Tue, 07 Jul 2015 12: 
-0700 Tue, 07 Jul 2015 12: 
-0700 Tue, 07 Jul 2015 12: 





-0700 Tue, 07 Jul 2015 12: 


Restart Count: 5 说 明 这 个 名 为 simmemleak 的 容器 被 强制 终止 并 重启 


了 5 次 。 


我 们 可 以 在 使 用 kubectl get pod 命 令 时 添加 -o go-template=... 格 式 参 





$ kubectl get pod -o go-template='{{range.status.contain: 


Container Name: simmemleak 


LastState: map[terminated:map[exitCode:137 reason:00M Ki 


这 里 我 们 可 以 看 到 这 个 容器 因为 reason: OOM Killed 而 被 强制 终 
止 ， 说 明 这 个 容器 的 内 存 超过 了 限制 (Out of Memory) 。 


6) 计算 资源 管理 的 演进 


当前 版 本 的 Kubernetes 中 的 Requests 和 Limits 都 是 作用 于 容器 级 别 
的 ， 未 来 Kubernetes 计 划 增 加 对 直接 作用 于 Pod 级 别 的 资源 配置 的 文 持 ， 
这 种 资源 配置 是 能 被 Pod 内 的 所 有 容器 共享 的 ， 包 括 emptyDir 这 种 Pod 级 
别 的 Volume。 


从 资源 的 种 类 来 看 ， 目 前 Kubernetes 只 能 支持 CPU 和 内 存 两 种 计算 
资源 类 型 ， 在 后 续 的 版 本 中 ，Kubernetes 计 划 支 持 更 多 的 资源 类 型 ， 包 
括 节 点 磁盘 空间 资源 ， 还 将 文 持 自 定 义 的 资源 类 型 。 





.资源 的 配置 范围 管理 (LimitRange) 


默认 情况 下 ，Kubernetes 的 Pod 会 以 无 限制 的 CPU 和 内 存 运 行 。 这 也 
就 意味 着 Kubernetes 系 统 中 任何 的 Pod 都 可 以 使 用 其 所 在 节点 上 的 所 有 可 
用 的 CPU 和 内 存 。 通 过 配置 Pod 的 计算 资源 Requests 和 Limits， 我 们 可 以 
限制 Pod 的 资源 使 用 ， 但 对 于 Kubernetes 集 群 管理 员 而 言 ， 配 置 每 一 个 
Pod 的 Requests 和 Limits 是 烦琐 且 限 制 性 过 强 的 。 更 多 的 时 候 ， 我 们 需要 
的 是 对 集群 内 Request 和 Limits 的 配置 做 一 个 全 局 的 统一 的 限制 。 常 见 的 
配置 场景 如 下 。 


。 集群 中 的 每 个 节点 有 2GB 内 存 ， 集 群 管理 员 不 希望 任何 Pod 申 请 超 


过 2GB 的 内 存 : 因为 整个 集群 中 没有 任何 节点 能 满足 超过 2GB 内 存 
的 请 求 。 如 果 某 个 Pod 的 内 存 配 置 超过 2GB， 那 么 该 Pod 将 永远 都 无 
法 被 调度 到 任何 节点 上 执行 。 为 了 防止 这 种 情况 的 发 生 ， 集 群 管理 
员 和 希望 能 在 系统 管理 功能 中 设置 茶 止 Pod 申 请 超过 2GB 内 存 。 
集群 由 同一 个 组 织 中 的 两 个 团队 共享 ， 各 自分 别 用 来 运行 生产 环境 
和 开发 环境 。 和 生产 环境 最 多 可 以 使 用 8GB 内 存 ， 而 开发 环境 最 多 可 
以 使 用 512MB 内 存 。 集 群 管理 员 和 希望 通过 为 这 两 个 环境 创建 不 同 的 
命名 空间 (namespace) 并 为 每 个 命名 空间 设置 不 同 的 限制 来 满足 
这 个 需求 。 

用 户 创 建 Pod 时 使 用 的 资源 可 能 会 刚好 比 整 个 机 器 资源 的 上 限 稍 小 
一 点 ， 而 恰好 剩 下 的 资源 大 小 非常 尴 答 : 不 足以 运行 其 他 任务 但 整 
个 集群 加 起 来 又 非常 浪费 。 因 此 ， 集 群 管理 员 希 望 设 置 每 个 Pod 必 
须 至 少 使 用 集群 平均 资源 值 (CPU 和 内 存 ) 的 20%， 这 样 集群 能 够 
提供 更 好 的 资源 一 致 性 的 调度 ， 从 而 减少 了 资源 浪费 。 








针对 这 些 需 求 ，Kubernetes 提 供 了 LimitRange 机 制 对 Pod 和 容器 的 
Requests 和 和 Limits 配 置 进一步 做 出 限制 。 在 下 面 的 示例 中 ， 将 说 明 如 何 
将 LimitsRange 应 用 到 一 个 Kubernetes 的 命名 空间 (namespace) 中 ， 然 后 
说 明 LimitRange 的 几 种 限制 方式 ， 比 如 最 大 及 最 小 范围 、Requests 和 
Limits 的 默认 值 、Limits 与 Requests 最 大 比例 上 限 等 。 


下 而 通过 LimitRange 的 设置 和 应 用 对 其 进行 说 明 。 
1) 创建 一 个 namespace 


创建 一 个 名 为 limit-example 的 namespace: 


$ kubectl create namespace limit-example 


namespace "limit-example" created 


2) 为 namespace 设 置 LimitRange 


为 namespace“limit-example” 创 建 一 个 简单 的 LimitRange。 创 建 
limits.yaml 配 置 文件 ， 内 容 如 下 : 


apiversion: v1 
kind: LimitRange 
metadata: 
name: mylimits 
spec: 
limits: 
- max: 
cpu: "4" 
memory: 2Gi 
min: 
cpu: 200m 
memory: 6Mi 
maxLimitRequestRatio: 
cpu: 3 
memory: 2 
type: Pod 
- default: 
Cpu: 300m 
memory: 200Mi 


defaultRequest: 


cpu: 200m 

memory: 100Mi 
max: 

cpu: "2" 

memory: 1Gi 
min: 

cpu: 100m 

memory: 3Mi 
maxLimitRequestRatio: 

cpu: 5 

memory: 4 


type: Container 
创建 该 LimitRange: 


$ kubectl create -f limits.yaml --namespace=limit-exampl 


limitrange "mylimits" created 


#34 namespacelimit-example'# HJ LimitRange: 


$ kubectl describe limits mylimits --namespace=limit-exa 
Name: mylimits 

Namespace: limit-example 

Type Resource Min Max Default Request 
Pod cpu 200m 4 - 


Pod memory 6Mi 2G1 - 


Container cpu 100m 2 200m300m 


Container memory 3Mi 1Gi 100Mi200Mi 





下 面 解 释 一 下 LimitRange 中 各 项 配置 的 意义 和 特点 。 





(1) 不 论 是 CPU 还 是 内 存 ， 在 LimitRange 中 ，Pod 和 Container 都 可 
以 设置 Min、Max 和 Max Limit/Requests Ratio 这 三 种 参数 。Container 还 可 
以 设置 Default Request 和 Default ”Limit 这 两 种 参数 ， 而 Pod 不 能 设置 
Default Request 和 Default Limit。 


(2) 对 Pod 和 Container 的 五 种 参数 的 解释 如 下 。 





e Container 的 Min (上 面 的 100m 和 3Mi) 是 Pod 中 所 有 容器 的 Requests 
值 的 下 限 ; Container 的 Max (上 面 的 2 和 1Gi) 是 Pod 中 所 有 容器 的 
Limits 值 的 上 限 ; Container 的 Default Request〈 上面 的 200m 和 
100Mi) 是 Pod 中 所 有 未 指定 Requests 值 的 容器 的 默认 Requests 值 ; 
Container 的 Default Limit (上 面 的 300m 和 200Mi)〉 是 Pod 中 所 有 未 指 
定 Limits 值 的 容器 的 默认 Limits 值 。 对 于 同一 资源 类 型 ， 这 4 个 参数 
必须 满足 以 下 关系 : Min<Default Request<Default Limit<Max。 

e Pod 的 Min (上面 的 200m 和 6Mi)〉 是 Pod 中 所 有 容器 的 Requests 值 的 
总 和 的 下 限 ，Pod 的 Max〈 上 面 的 4 和 2Gi) 是 Pod 中 所 有 容器 的 
Limits 值 的 总 和 的 上 限 。 当 容器 未 指定 Requests 值 或 者 Limits 值 时 ， 
将 使 用 Container 的 Default Request 值 或 者 Default Limit 值 。 

e Container 的 Max Limit/Requests Ratio 〈 上 面 的 5 和 4) 限制 了 Pod 中 所 
有 容器 的 Limits 值 与 Requests 值 的 比例 上 限 ; 而 Pod 的 Max 
Limit/Requests Ratio (上面 的 3 和 2) 限制 了 Pod 中 所 有 容器 的 Limits 
值 总 和 与 Requests 值 总 和 的 比例 上 限 。 




















(3) 如果 设 置 了 Container 的 Max， 那 么 对 于 该 类 资源 而 言 ， 整 个 
集群 中 的 所 有 容器 都 必须 设置 Limits， 耕 则 将 无 法 成 功 创建 。Pod 内 的 容 
器 未 配置 Limits 时 ， 将 使 用 Default ”Limit 的 值 〈 本 例 中 的 300m ”CPU 和 
200Mi 内 存 ) ， 而 如 果 Default 也 未 配置 则 无 法 成 功 创 建 。 


(4) 如 果 设 置 了 Container 的 Min， 那 么 对 于 该 类 资源 而 言 ， 整 个 进 
群 中 的 所 有 容器 都 必须 设置 Requests。 如 果 创 建 Pod 的 容器 时 未 配置 该 类 
资源 的 Requests， 那 么 创建 过 程 会 报 验证 错误 。Pod 里 容器 的 Requests 在 
未 配置 时 ， 可 以 使 用 默认 值 defaultRequest〈 本 例 中 的 200m CPU 和 100Mi 
WE); 如 果 未 配置 而 又 没有 defaultRequest， 那 么 会 默认 等 于 该 容器 的 
Limits; 如 果 此 时 Limits 也 未 定义 ， 那 么 就 会 报错 。 


(5) 对 于 任意 一 个 Pod 而 言 ， 该 Pod 中 所 有 容器 的 Requests 总 和 必 
须 大 于 或 等 于 6Mi， 而 且 所 有 容器 的 Limits 总 和 必须 小 于 或 等 于 1Gi;， 同 
样 ， 所 有 容器 的 CPU Requests 总 和 必须 大 于 或 等 于 200m， 而 且 所 有 容器 
的 CPU Limits 总 和 必须 小 于 或 等 于 2。 


(6) Pod 里 任何 容器 的 Limits 与 Requests 的 比例 不 能 超过 Container 
的 Max Limit/Requests Ratio; Pod 里 所 有 容器 的 Limits 总 和 与 Requests 的 
总 和 的 比例 不 能 超过 Pod 的 Max Limit/Requests Ratio。 


3) 创建 Pod 时 触发 LimitRange 限 制 
最 后 ， 让 我 们 看 看 LimitRange 生 效 时 对 容器 的 资源 限制 效果 。 


命名 空间 中 的 限制 (LimitRange〉 只 会 在 Pod 创 建 或 者 更 新 的 时 候 
执行 检查 。 如 果 手 动 修改 限制 (LimitRange)〉 为 一 个 新 的 值 ， 那 么 这 个 
新 的 值 不 会 去 检查 或 限制 之 前 已 经 在 该 命名 空间 中 创建 好 的 Pod。 








如 果 用 户 创建 Pod 时 ， 配 置 的 资源 值 《CPU 或 者 内 存 ) 超过 了 
LimitRange 的 限制 ， 那 么 该 创建 过 程 会 报错 ， 在 错误 信息 中 会 说 明 详细 
的 错误 原因 。 





下 面 通过 创建 一 个 单 容 器 Pod 来 展示 默认 限制 是 如 何 配置 到 Pod 上 
的 ; 


$ kubectl run nginx --image=nginx --replicas=1 --namespa 


deployment "nginx" created 


查看 已 创建 的 Pod: 


$ kubectl get pods --namespace=limit-example 


NAME READY STATUS RESTARTS 


nginx - 2040093540 -s8vzu 1/1 Running 0 


查看 该 Pod 的 resources 相 关 信 息 : 


$ kubectl get pods nginx-2040093540-s8vzu --namespace=1li 
resourceVersion: "57" 
selfLink: /api/vi/namespaces/limit -example/pods/nginx- 
uid: 67b20741-f53b-11e5-b066 -64510658e388 
spec: 
containers: 
- image: nginx 
imagePullPolicy: Always 
name: nginx 


resources: 


limits: 
cpu: 300m 
memory: 200Mi 
requests: 
cpu: 200m 
memory: 100Mi 
terminationMessagePath: /dev/termination-log 


volumeMounts: 


由 于 该 Pod 未 配置 资源 Requests 和 Limits， 所 以 使 用 了 
namespacelimit-example 中 的 默认 CPU 和 内 存 定 义 的 Requests 和 Limits 值 。 


下 面 创建 一 个 超出 资源 限制 的 Pod “使 用 3CPU) : 


invalid-pod.yaml: 
apiversion: v1 
kind: Pod 
metadata: 

name: invalid-pod 

spec: 

containers: 

- name: kubernetes-serve-hostname 
image: gcr.io/google_containers/serve_hostname 
resources: 

limits: 
cpu: "3" 


memory: 100Mi 


创建 该 Pod， 可 以 看 到 系统 报错 了 ， 并 且 提 供 了 错误 原因 为 超过 了 
限制 。 


$ kubectl create -f invalid-pod.yaml --namespace=limit-e 


Error from server: error when creating "invalid-pod.yaml 


接 下 来 的 例子 展示 了 LimitRange 对 maxLimitRequestRatio 的 限制 : 


limit-test-nginx.yaml: 
apiVersion: v1 

kind: Pod 

metadata: 

name: limit-test-nginx 

labels: 
name: limit-test-nginx 

spec: 

containers: 

- name: limit-test-nginx 
image: nginx 
resources: 

limits: 
cpu: "1" 
memory: 512Mi 
requests: 
cpu: "0.8" 


memory: 250Mi 


由 于 limit-test-nginx 这 个 Pod 的 全 部 内 存 Limits 总 和 与 Redquests 总 和 的 
比例 为 512 : 250， 大 于 LimitRange 中 定义 的 Pod 的 内 存 
maxLimitRequestRatio 值 2， 因 此 创建 会 失败 : 


$ kubectl create -f limit-test-nginx.yaml --namespace=1l1i 


Error from server: error when creating "limit-test-nginx 


下 面 的 例子 为 满足 LimitRange 限 制 的 Pod: 


valid-pod.yaml: 
apiversion: v1 
kind: Pod 
metadata: 

name: valid-pod 

labels: 
name: valid-pod 

spec: 

containers: 

- name: kubernetes-serve-hostname 
image: gcr.io0/google_containers/serve_hostname 
resources: 

limits: 
cpu: "1" 


memory: 512Mi 


创建 Pod 将 会 成 功 : 


$ kubectl create -f valid-pod.yaml --namespace=limit-exa 


pod "valid-pod" created 
租 看 该 Pod 的 资源 信息 : 


$ kubectl get pods valid-pod --namespace=limit-example - 
uid: 3bibfd7a-f53c-11e5-b066 -64510658e388 
spec: 
containers: 
- image: gcr.io0/google_containers/serve_hostname 
imagePullPolicy: Always 
name: kubernetes-serve-hostname 
resources: 
limits: 
cpu: "1" 
memory: 512Mi 
requests: 
cpu: "1" 


memory: 512Mi 


可 以 看 到 该 Pod 配 置 了 明确 的 Limits 和 Requests， 因 此 该 Pod 不 会 使 
用 namespacelimit-example 中 定义 的 default 和 defaultRequest。 





需要 注意 的 是 ，CPU Limits 强 制 配置 这 个 选项 在 Kubernetes 集 群 中 
默认 是 开局 的 ;除非 集群 管理 员 在 部 署 kubelet 时 ， 通 过 设置 参数 --cpu- 
cfs-quota=false 来 关闭 该 限制 : 





$ kubelet --help 
Usage of kubelet 


--cpu-cfs-quota[=true]: Enable CPU CFS quota enforcement 


$ kubelet --cpu-cfs-quota=false ... 


如 果 集 群 管理 员 希 望 对 整个 集群 中 容器 或 者 Pod 配 置 的 Requests 和 
Limits 做 限制 ， 那 么 可 以 通过 配置 Kubernetes 的 命名 空间 (namespace) 
上 的 LimitRange《〈 资 源 限 制 区 间 ) 来 达到 该 目的 。 在 Kubernetes 集 群 
中 ， 如 果 Pod 没 有 显 式 定义 Limits 和 Requests， 那 么 Kubernetes 系 统 会 将 
该 Pod 所 在 的 命名 空间 中 定义 的 LimitRange 的 default 和 defaultRequests 配 
置 到 该 Pod 上 。 


3. 资源 的 服务 质量 管理 (ResourceQoS ) 


本 节 对 Kubernetes 如 何 根据 Pod 的 Requests 和 Limits 配 置 来 实现 针对 
Pod 的 不 同 级 别 的 资源 服务 质量 控制 QoS) 进行 说 明 。 


在 Kubernetes 的 资源 QoS 体系 中 ， 需 要 保证 高 可 靠 性 的 Pod 可 以 申请 
可 靠 资源 ， 而 一 些 不 需要 高 可 靠 性 的 Pod 可 以 申请 可 靠 性 较 低 或 者 不 可 
靠 的 资源 。 在 计算 资源 一 节 中 ， 我 们 讲 到 了 容器 的 资源 配置 分 为 
Requests 和 Limits， 其 中 Requests 是 Kubernetes 调 度 时 能 为 容器 提供 的 完 
全 可 保障 的 资源 量 〈 最 低 保障 ) ， 而 Limits 是 系统 允许 容器 运行 时 可 能 
使 用 到 的 资源 量 的 上 限 (最 高 上 限 ) 。Pod 级 别 的 资源 配置 是 通过 计算 
Pod 内 所 有 容器 的 资源 配置 的 总 和 得 出 来 的 。 














Kubernetes 中 Pod 的 Requests 和 Limits 资 源 配置 有 如 下 特点 : 如 果 Pod 


配置 的 Requests 值 等 于 Limits 值 ， 那 么 该 Pod 可 以 获得 的 资源 是 完全 可 靠 
的 ; 而 如 果 Pod 的 Requests 值 小 于 Limits 值 ， 那 么 该 Pod 获 得 的 资源 可 分 
成 两 部 分 : 一 部 分 是 完全 可 靠 的 资源 ， 资 源 量 大 小 等 于 Requests 值 ; 男 
外 一 部 分 是 不 可 靠 的 资源 ， 这 部 分 资源 最 大 等 于 Limits 与 Requests 的 差 
额 值 ， 这 份 不 可 靠 的 资源 能 够 申请 到 多 少 ， 则 取决 于 当时 主机 上 容器 可 
用 资源 的 余 量 。 


通过 这 种 机 制 ，Kubernetes 可 以 实现 节点 资源 的 超 售 (Over 
Subscription〉， 比 如 在 CPU 完 全 充足 的 情况 下 ， 某 机 器 共有 32GiB 内 存 
可 提供 给 容器 使 用 ， 容 器 配置 为 Requests 值 1GiB，Limits 值 为 2GiB， 那 
么 该 机 器 上 最 多 可 以 同时 运行 32 个 容器 ， 每 个 容器 最 多 可 使 用 2GiB 内 
存 ， 如 果 这 些 容器 的 内 存 使 用 峰值 错开 ， 那 么 所 有 容器 也 可 以 一 直 正 常 
运行 。 











超 售 机 制 能 有 效 地 提高 资源 的 利用 率 ， 同 时 不 会 影响 容器 申请 的 完 
全 可 靠 资 源 的 可 靠 性 。 


1) Requests 和 Limits 对 不 同 计算 资源 类 型 的 限制 机 制 


根据 计算 资源 章节 的 内 容 我 们 知道 ， 容 器 的 资源 配置 满足 以 下 两 个 


条 件 。 


e Requests<= 节 点 可 用 资源 。 


e Requests<=Limits。 


Kubernetes 根 据 Pod 配 置 的 Requests 值 来 调度 Pod，Pod 在 成 功 调度 之 
后 会 得 到 Requests 值 定义 的 资源 来 运行 ， 而 如 果 Pod 所 在 机 器 上 的 资源 有 
空余 ， 则 Pod 可 以 申请 更 多 的 资源 ， 最 多 不 能 超过 Limits 的 值 。 我 们 下 面 
看 一 下 Requests 和 Limits 针 对 不 同 计 算 资 源 类 型 的 限制 机 制 的 差异 。 这 


种 差异 主要 取决 于 计算 资源 类 型 是 可 压缩 资源 还 是 不 可 压缩 资源 。 
(1) 可 压缩 资源 


e Kubernetes 目 前 支持 的 可 压缩 资源 是 CPU。 

。Pod 可 以 得 到 Pod 的 Requests 配 置 的 CPU 使 用 量 ， 而 是 人 否 能 使 用 超过 
Requests 值 的 部 分 取决 于 系统 的 负载 和 调度 。 不 过 由 于 目前 
Kubernetes 和 Docker 的 CPU 陋 离 机 制 都 是 在 容器 级 别 隔 离 的 ， 所 以 
Pod 级 别 的 资源 配置 并 不 能 完全 得 到 保障 ; Pod 级 别 的 cgroups 正 在 
紧锣密鼓 地 开发 中 ， 如 果 将 来 引入 ， 就 可 以 确保 Pod 级 别 的 资源 配 
置 准确 运行 。 

空 闪 CPU 资 源 按照 容器 Requests 值 的 比例 分 配 。 举 例 说 明 :; 容器 A 
的 CPU 配 置 为 Requests ”1Limits 10， 容器 B 的 CPU 配 置 为 request 
2Limits ”8，A 和 B 同 时 运行 在 一 个 节点 上 ， 初 始 状 态 下 容器 的 可 用 
CPU 为 3cores， 那 么 A 和 B 恰 好 得 到 它们 的 Requests 中 定义 的 CPU 用 
量 ， 即 1CPU 和 2CPU。 如 果 A 和 B 都 需要 更 多 的 CPU 资源 ， 而 恰好 
此 时 系统 的 其 他 任务 释放 出 1.5CPU， 那 么 这 1.5CPU 将 按照 A 和 B 的 
Requests 值 的 比例 1 : 2 分 配给 A 和 B， 即 最 终 A 可 使 用 1.5CPU，B 可 
使 用 3CPU。 

如 果 Pod 使 用 了 超过 Limits 10 中 配置 的 CPU 用 量 ， 那 么 cgroups 会 对 
Pod 中 的 容器 的 CPU 使 用 进行 限 流 (throttled) ; 如 果 Pod 没 有 配置 
Limits 10， 那 么 Pod 会 答 试 抢占 所 有 空闲 的 CPU 资源 〈Kubernetes 从 
1.2 版 本 开始 默认 开启 --cpu-cfs-quota， 因 此 默认 情况 下 必须 配置 


Limits) 。 


(2) 不 可 压缩 资源 


e Kubernetes 目 前 支持 的 可 压缩 资源 是 内 存 。 


e Pod 可 以 得 到 Requests 中 配置 的 内 存 。 如 果 Pod 使 用 的 内 存量 小 于 它 
的 Requests 的 配置 ， 那 么 这 个 Pod 可 以 正常 运行 (除非 出 现 操 作 系 统 
级 别 的 内 存 不 足 等 严重 问题 )》 ;如 果 Pod 使 用 的 内 存量 超过 了 它 的 
Requests 的 配置 ， 那 么 这 个 Pod 有 可 能 被 Kubermmetes“ 杀 挥 ”: 比如 Pod 
A 使 用 了 超过 Requests 而 不 到 Limits 的 内 存量 ， 此 时 同一 机 器 上 另外 
一 个 Pod B 之 前 只 使 用 了 远 少 于 上 自己 的 Requests 值 的 内 存 ， 而 此 时 程 
序 压力 增 大 ，Pod B 癌 系统 申请 的 总 量 不 超过 自己 的 Requests 值 的 内 
存 ， 那 么 Kubernetes 可 能 会 直接 杀 挥 Pod A; 另外 一 种 情况 是 Pod A 
使 用 了 超过 Requests 而 不 到 Limits 的 内 存量 ， 此 时 Kubernetes 将 一 个 
新 的 Pod 调 度 到 这 台 机 器 上 ， 新 的 Pod 需 要 使 用 内 存 ， 而 只 有 Pod A 
使 用 了 超过 了 自己 的 Requests 值 的 内 存 ， 那 么 Kubernetes 也 可 能 会 杀 
掉 Pod A 来 释放 内 存 资源 。 

如 果 Pod 使 用 的 内 存量 超过 了 它 的 Limits 设 置 ， 那 么 操作 系统 内 核 会 
杀 掉 Pod 有 所 有 容器 的 所 有 进程 中 使 用 内 存 最 多 的 一 个 ， 直 到 内 存 不 
超过 Limits 为 止 。 














2) 对 调度 策略 的 影响 


Kubernetes 的 kubelet 通 过 计算 Pod 中 所 有 容器 的 Requests 的 总 和 来 决 
定 对 Pod 的 调度 。 

不 管 是 CPU 还 是 内 存 ，Kubernetes 调 度 器 和 kubelet 都 会 确保 节点 上 
所 有 Pod 的 Requests 的 总 和 不 会 超过 该 节点 上 可 分 配给 容器 使 用 的 资 
源 容 量 上 限 。 





3) 服务 质量 等 级 (QoS Classes) 


在 一 个 超 用 (Over Committed， 即 容器 Limits 总 和 大 于 系统 容量 上 
限 ) 系统 中 ， 由 于 容器 负载 的 波动 可 能 导致 操作 系统 的 资源 不 足 ， 最 终 


可 能 会 导致 部 分 容器 被 “ 杀 掉 ”"。 在 这 种 情况 下 ， 我 们 当然 会 希望 优 

先 “ 杀 挥 ” 那 些 不 太 重 要 的 容器 ， 那 么 如 何 衡 量 重要 程度 呢 ? Kubernetes 
将 容器 划分 成 3 个 QoS 等 级 : Guaranteed (完全 可 靠 的 ) ~ Burstable (5% 
性 波动 、 较 可 靠 的 ) 和 Best-Effort( 尺 力 而 为 、 不 太 可 靠 的 ) ， 这 三 种 
优先 级 依次 递减 ， 如 图 5.4 所 示 。 


Burstable ve 
Best Effort (S 


图 5.4 QoS 等 级 和 优先 级 的 关系 












从 理论 上 来 说 ，QoS 级 别 应 该 作为 一 个 单独 的 参数 来 提供 API， 并 
由 用 户 对 Pod 进 行 配置 ， 这 种 配置 应 该 与 Requests 和 Limits 无 关 。 但 在 当 
前 版 本 的 Kubernetes 的 设计 中 ， 为 了 简化 模式 及 避免 引入 太 多 的 复杂 
性 ，QoS 级 别 直 接 由 Requests 和 Limits 来 定义 。 在 Kubernetes 中 容器 的 
QoS 级 别 等 于 容器 所 在 Pod 的 QoS 级 别 ， 而 Kubernetes 的 资源 配置 定义 了 
Pod 的 三 种 QoS 级 别 ， 如 下 所 述 。 





1) Guaranteed 〈 完 全 可 靠 的 ) 


如 果 Pod 中 的 所 有 容器 对 所 有 资源 类 型 都 定义 了 Limits 和 Requests， 
并 且 所 有 容器 的 Limits 值 都 和 Requests 值 全 部 相等 〈 且 都 不 为 0) ， 那 么 
该 Pod 的 QoS 级 别 束 是 Guaranteed。 注 意 : 在 这 种 情况 下 ， 容 器 可 以 不 定 
义 Requests， 因 为 Requests 值 在 未 定义 的 时 候 默 认 等 于 Limits。 





下 面 这 两 个 例子 中 定义 的 Pod QoS 级 别 就 是 Guaranteed: 


containers: 
name: foo 
resources: 
limits: 
cpu: 10m 
memory: 1Gi 
name: bar 
resources: 
limits: 
cpu: 100m 


memory: 100Mi 


在 上 面 的 例子 中 未 定义 Requests 值 ， 所 以 其 默认 等 于 Limits 值 。 而 
下 面 这 个 例子 中 定义 的 Requests 和 Limits 的 值 完全 相同 : 


containers: 
name: foo 
resources: 
limits: 


cpu: 10m 


memory: 1Gi 
requests: 
cpu: 10m 


memory: 1Gi 


name: bar 
resources: 
limits: 
cpu: 100m 
memory: 100Mi 
requests: 


cpu: 10m 


memory: 1Gi 


2) Best-Effort OS Fim A. AA SER) 


如 果 Pod 中 所 有 容器 都 未 定义 资源 配置 (Requests 和 Limits 都 未 定 
X) ， 那 么 该 Pod 的 QoS 级 别 就 是 Best-Effort。 


例如 下 面 这 个 Pod 定 义 : 


containers: 
name: foo 
resources: 
name: bar 


resources: 


3) Burstable (弹性 波动 、 较 可 靠 的 ) 


当 一 个 Pod 既 不 是 Guaranteed 级 别 的 ， 也 不 是 Best-Effort 级 别 的 时 ， 
该 Pod 的 QoS 级 别 就 是 Burstable。Burstable 级 别 的 Pod 包 括 两 种 情况 。 第 1 
种 情况 是 : Pod 中 的 一 部 分 容器 在 一 种 或 多 种 资源 类 型 的 资源 配置 中 ， 
定义 了 Requests 值 和 Limits 值 〈 都 不 为 0) ， 且 Requests 值 小 于 Limits 值 ; 
第 2 种 情况 是 : Pod 中 的 一 部 分 容器 未 定义 资源 配置 (Requests Limits 
都 未 定义 ) 。 注 意 : 容器 未 定义 Limits 时 ，Limits 值 默认 等 于 节点 资源 
容量 上 限 。 


下 面 几 个 例子 中 的 Pod 的 QoS 等 级 都 是 Burstable。 


(1) 容器 foo 的 CPU Requests 不 等 于 Limits: 


containers: 
name: foo 
resources: 
limits: 
cpu: 10m 
memory: 1Gi 
requests: 
cpu: 5m 
memory: 1Gi 
name: bar 
resources: 
limits: 
cpu: 10m 


memory: 1Gi 


requests: 


cpu: 10m 


memory: 1Gi 


(2) 容器 bar 未 定义 资源 配置 而 容器 foo 定 义 了 资源 配置 : 


containers: 
name: foo 
resources: 
limits: 
cpu: 10m 
memory: 1Gi 
requests: 
cpu: 10m 
memory: 1Gi 
name: bar 


(3) 容器 foo 未 定义 CPU， 而 容器 bar 未 定义 内 存 : 


containers: 
name: foo 
resources: 
limits: 
memory: 1Gi 
name: bar 
resources: 
limits: 


cpu: 100m 


(4) 容器 bar 未 定义 资源 配置 ， 而 容器 foo 未 定义 Limits 值 : 


containers: 
name: foo 
resources: 
requests: 
Cpu: 10m 
memory: 1Gi 


name: bar 


4) Kubernetes QoS 的 工作 特点 


Pod 的 CPU Requests 无 法 得 到 满足 (比如 节点 的 系统 级 任务 占用 过 
多 的 CPU 导致 无 法 分 配给 足够 的 CPU 给 容器 使 用 ) 时 ， 容 器 得 到 的 CPU 
会 被 压缩 限 流 。 





内 存 由 于 是 不 可 压缩 资源 ， 所 以 针对 内 存 资 源 紧缺 的 情况 ， 将 按照 
以 下 逻辑 进行 处 理 。 


(1) Best-Effort Pod 的 优先 级 最 低 ， 这 类 Pod 中 运行 的 进程 会 在 系 
统 内 存 暴 缺 时 被 第 一 优先 “ 杀 死 ”。 当 然 ， 从 愉 外 一 个 角度 来 看 ，Best- 
Effort Pod 由 于 没有 设置 资源 Limits， 所 以 在 资源 充足 的 时 候 ， 它 们 可 以 
充分 地 使 用 所 有 的 闲置 资源 。 


(2) Burstable Pod 的 优先 级 居中 ， 这 类 Pod 初 始 时 会 分 配 较 少 的 可 
靠 资 源 ， 但 可 以 按 需 申请 更 多 的 资源 。 当 然 ， 如 果 整 个 系统 内 存 紧 缺 ， 
而 又 没有 Best-Effort 容 器 可 以 被 “ 杀 死 ”以 释放 资源 ， 则 这 类 Pod 中 的 进程 
可 能 会 被 “ 杀 死 ”。 


(3) Guaranteed Pod 的 优先 级 最 高 ， 而 且 一 般 情况 下 这 类 Pod 只 要 


不 超过 其 资源 Limits 的 限制 就 不 会 被 * 杀 死 ”。 当 然 ， 如 宁 整 个 系统 闪存 
紧缺 ， 而 又 没有 其 他 更 低 优 先 级 的 容 圳 可 以 被 “ 杀 死 "以 释放 资源 ， 这 类 
Pod 中 的 进程 也 可 能 会 被 < 杀 死 ”。 


5) OOM 计 分 系统 
OOM (Out Of Memory) 计 分 规则 包括 如 下 内 容 。 


OOM 计 分 是 一 个 进程 消耗 内 存在 系统 中 占 的 百分比 中 不 含 百 分 号 
的 数字 的 值 乘 以 10 的 结果 ， 这 个 结果 是 进程 OOM 基 础 分 ， 将 进程 
OOM 基 础 分 的 分 值 再 加 上 这 个 进程 的 OOM 分 数 调整 值 
OOM_SCORE_ADJ 的 值 作为 进程 OOM 最 终 分 值 〈 除 root 启 动 的 进 
程 外 ) 。 在 系统 发 生 OOM 时 ，OOM Killer 会 优先 杀 掉 OOM 计 分 更 
高 的 进程 。 

进程 的 OOM 计 分 的 基本 分 数值 范围 是 0 一 1000， 如 果 A 进 程 的 调整 
值 OOM_SCORE_ADJ 减 去 B 进 程 的 调整 值 的 结果 大 于 1000， 那 么 A 
进程 的 OOM 计 分 最 终 值 必然 大 于 B 进 程 ，A 进 程 会 比 B 进 程 优先 被 
不 论调 整 值 OOM_SCORE_ADIJ 为 多 少 ， 任 何 进程 的 最 终 分 值 范 
也 是 0 一 1000。 


图 


在 Kubernetes， 不 同 QoS 的 OOM 计 分 调整 值 规则 如 表 5.1 所 示 。 


表 5.1 不 同 QoS 的 OOM 计 分 调整 值 


Qos 等 级 oom_score_adj 


Guaranteed -998 








BestEffort 1000 





Burstable min(max(2. 1000 - (1000 * memoryRequestBytes) 








machineMemoryCapacityBytes). 999) 


e Best-effort ”Pod 设置 OOM_SCORE_ADJ 调 整 值 为 1000， 因 此 Best- 
effort Pod 中 的 容器 里 面 的 所 有 进程 的 OOM 最 终 分 肯定 是 1000。 

e Guaranteed Pod 设 置 OOM_SCORE_ADJ 调 整 值 为 -998， 因 此 
Guaranteed ”Pod 中 的 容器 里 面 的 所 有 进程 的 OOM 最 终 分 一 般 为 0 或 
者 1 因为 基础 分 不 可 能 为 1000) 。 

e Burstable Pod 规 则 分 情况 说 明 : 如 果 Burstable Pod 的 内 存 Requests 超 
过 了 系统 可 用 内 存 的 99.8%， 那 么 这 个 Pod 的 OOM_SCORE_ADJ 调 
整 值 固 定 为 2， 否 则 ， 设 置 OOM_SCORE_ADJ 调 整 值 为 1000- 

10《 内 存 Requests 占 系统 可 用 内 存 的 百分比 的 无 百 分 号 的 数字 部 分 
的 值 ) ， 而 如 果 内 存 Requests 为 0， 那 么 OOM_SCORE_ADJ 调 整 值 
固定 为 999。 这 样 的 规则 能 确保 OOM_SCORE_ADJ 调 整 值 的 范围 为 
2 一 999， 而 Burstable Pod 中 所 有 进程 的 OOM 最 终 分 数 范围 为 2 一 
1000. Burstable Pod 进 程 的 OOM 最 终 分 数 始 终 大 于 Guaranteed Pod 
的 进程 得 分 ， 因 此 它们 会 被 优先 * 杀 死 ”。 如 果 一 个 Burstable Pod 使 
用 的 内 存 比 它 的 内 存 Requests 少 ， 那 么 可 以 肯定 的 是 它 的 所 有 进程 
的 OOM 最 终 分 数 会 小 于 1000， 此 时 能 确保 它 的 优先 级 高 于 Best- 
effort Pod。 如 果 一 个 Burstable Pod 的 某 个 容器 中 某 个 进程 使 用 的 内 
存 比 容器 的 request 值 高 ， 那 么 这 个 进程 的 OOM 最 终 分 数 会 是 

1000， 人 否则 它 的 OOM 最 终 分 会 小 于 1000。 假 设 下 面容 器 中 有 一 个 
占用 内 存 非常 大 的 进程 ， 那 么 当 一 个 使 用 内 存 超过 其 Requests 的 
Burstable Pod 与 男 外 一 个 使 用 内 存 少 于 其 Requests 的 Burstable Pod 
生 内 存 范 争 冲突 时 ， 前 者 的 进程 会 被 系统 “ 杀 掉 ”"。 如 果 一 个 
Burstable Pod 内 部 有 多 个 进程 的 多 个 容器 发 生 内 存 竞争 冲突 ， 那 么 





此 时 OOM 评 分 只 能 作为 参考 ， 不 能 保证 完全 按照 资源 配置 的 定义 
来 执行 OOM Kill. 


OOM 还 有 一 些 特殊 的 计 分 规则 ， 如 下 所 述 。 


kubelet 进 程 和 和 Docker 进 程 的 调整 值 OOM_SCORE_ADJ 为 -998。 
如 果 配 置 进程 调整 值 OOM SCORE _ADJ 为 -999， 那 么 这 类 进程 不 
会 被 OOM Killer“ 杀 掉 ”。 


6) QoS 的 演进 








目前 Kubernetes 基 于 QoS 的 超 用 机 制 日 趋 完善 ， 但 还 有 一 些 问题 需 
要 解决 。 


7) 内 存 Swap 的 文 持 


当前 的 QoS 策略 都 是 假定 主机 不 司 用 内 存 Swap。 如 果 主 机 局 用 了 
Swap， 那 么 上 面 的 QoS 策略 可 能 会 失效 。 举 例 说 明 : 两 个 Guaranteed 
Pod 都 刚好 达到 了 内 存 Limits， 那 么 由 于 内 存 Swap 机 制 ， 它 们 还 可 以 继 
续 申 请 使 用 更 多 的 内 存 。 如 果 Swap 空 间 不 足 ， 那 么 最 终 这 两 个 Pod 中 的 
进程 可 能 会 被 “ 杀 掉 >”。 由 于 Kubernetes 和 Docker 尚 不 支持 内 存 Swap 空 间 
的 隔离 机 制 ， 所 以 这 一 功能 暂时 还 未 实现 。 


8) EEE QoS Mg 


当前 的 QoS 策略 都 是 基于 Pod 的 资源 配置 《Requests 和 Limits) 来 定 
义 的 ， 而 资源 配置 本 身 又 承担 着 对 Pod 资 源 管 理 和 限制 的 功能 。 两 种 不 
同 维度 的 功能 使 用 同一 个 参数 来 配置 ， 可 能 会 导致 菜 些 复杂 需求 无 法 满 
足 ， 比 如 当前 Kubernetes 无 法 文 持 弹 性 的 、 高 优先 级 的 Pod。 自 定义 QoS 
优先 级 能 提供 更 大 的 灵活 性 ， 完 美 地 实现 各 类 需求 ， 但 同时 会 引入 更 高 




















的 复杂 性 ， 而 且 过 于 灵活 的 设置 会 给 予 用 户 过 高 的 权限 ， 对 系统 管理 也 
提出 了 更 大 的 挑战 。 


.资源 的 配额 管理 (Resource Quotas) 


如 果 一 个 Kubernetes 和 集群 被 多 个 用 户 或 者 多 个 团队 共享 使 用 ， 那 么 
就 需要 考虑 共享 时 对 资源 公平 使 用 的 问题 ， 因 为 某 个 用 户 可 能 会 使 用 超 
过 基于 公平 原则 分 配给 其 的 资源 量 。 





资源 配额 (Resource Quotas) 就 是 解决 这 个 问题 的 工具 。 通 过 
ResourceQuota 对 象 ， 我 们 可 以 定义 一 项 资源 配额 ， se 
每 一 个 命名 空间 Cnamespace) 提供 一 个 总 体 的 资源 使 用 的 限制 : 
以 限制 命名 空间 中 某 种 类 型 的 对 象 的 总 数目 上 限 ， 也 可 以 设置 命 四 
中 Pod 可 以 使 用 到 的 计算 资源 的 总 上 限 。 


典型 的 资源 配额 (Resource Quotas) 使 用 方式 如 下 。 





不 同 的 团队 工作 在 不 同 的 命名 空间 下 ， 目 前 这 个 是 非 约 束 性 的 ， 未 
来 版 本 中 可 能 会 通过 ACLs 访问 控制 列表 Access Control List) 的 


方式 来 实现 强制 性 约束 。 
。 集群 管理 员 为 集群 中 的 每 个 命名 空间 创建 一 个 或 者 多 个 资源 配额 
项 。 


当 用 户 在 命名 空间 中 使 用 资源 (创建 Pod 或 者 Service 等 ) 时 ， 
Kubernetes 的 配额 系统 会 统计 、 监 控 和 检查 资源 用 量 ， 以 确保 使 用 
的 资源 用 量 没有 超过 资源 配额 的 配置 。 

如 果 创 建 或 者 更 新 应 用 时 ， 资 源 使 用 超过 了 某 项 资源 配额 的 限制 ， 
那么 创建 或 者 更 新 的 请 求 会 报错 (HTTP 403Forbidden) ， 错 误 信 
恩 给 出 详细 的 出 错 原 因 说 明 。 


如 果 命 名 空间 中 的 计算 资源 (CPU 和 内 存 ) 的 资源 配额 启用 ， 那 么 
用 户 必须 为 相应 的 资源 类 型 设置 Requests 或 Limits; 否则 配额 系统 
可 能 会 直接 拒绝 Pod 的 创建 。 这 里 可 以 使 用 LimitRange 机 制 来 为 没 
有 配置 资源 的 Pod 提 供 默认 资源 配置 。 


下 面 的 例子 展示 了 一 个 非常 适合 使 用 资源 配额 来 做 资源 控制 管理 的 


场景 。 


集群 共有 32GB 内 存 和 16CPU， 两 个 小 组 ，A 小 组 使 用 20GB 内 存 和 
10CPU，B 小 组 使 用 10GB 内 存 和 2CPU， 剩 下 的 2GB 内 存 和 2CPU 作 
为 预 留 。 

在 名 为 testing 的 命名 空间 中 ， 限 制 使 用 1CPU 和 1GB 内 存 ; 在 名 为 
production 的 命名 空间 中 ， 资 源 使 用 不 受 限 制 。 











在 使 用 资源 配额 时 ， 需 要 注意 以 下 两 点 。 


如 采集 群 中 总 的 可 用 资源 小 于 各 命名 空间 中 资源 配额 的 总 和 ， 和 那么 
可 能 会 导致 资源 竞争 。 资 源 竞争 时 ，Kubernetes 系 统 使 用 先 到 先 得 
的 原则 。 

不 管 是 资源 竞争 还 是 配额 的 修改 都 不 会 影响 到 已 经 创建 的 资源 使 用 
对 象 。 


1) 在 Master 中 开局 资源 配额 选 型 


资源 配额 可 以 通过 在 kube-apiserver 的 --admission-control= 参 数值 中 


添加 ResourceQuota 参 数 进 行 开启 。 如 果菜 个 命名 空间 的 定义 中 存在 
ResourceQuota， 那 么 对 于 该 命名 空间 而 言 ， 资 源 配 额 就 是 开启 的 。 一 个 
命名 空间 可 以 有 多 个 ResourceQuota 配 置 项 。 


(1) 计算 资源 配额 (Compute Resource Quota) 


资源 配额 可 以 限制 一 个 命名 空间 中 所 有 Pod 的 计算 资源 的 总 和 。 表 
5.2 列 出 了 目前 Kubernetes 资 源 配额 支持 限制 的 计算 资源 类 型 。 


表 5.2 ”ResourceQuota 的 计算 资源 类 型 


资源 名 称 说 AA 
cpu 终止 状态 的 Pod, CPU Requests 的 总 和 不 能 超过 该 值 
limits.cpu : 终 1 的 Pod, CPU Limits 的 总 和 不 能 超过 该 值 
limits.memory PAI 的 Pod， 内 存 Limits 的 总 和 不 能 超过 该 值 
memory pe J Pod， 内 存 Requests 的 总 和 不 能 超过 该 值 

















requests.cpu EX 的 Pod, CPU Requests 的 总 和 不 能 超过 该 值 























requests.memory kx 的 Pod， 内 存 Requests 的 总 和 不 能 超过 该 值 


(2) 对 象 数量 配额 (Object Count Quota) 


指定 类 型 的 对 象 数 量 可 以 被 限制 。 表 5.3 列 出 了 Kubernetes 资 源 配 额 
支持 限制 对 象 数 量 的 对 象 类 型 。 


表 5.3 ”ResourceQuota 的 对 象 类 型 


资源 名 称 说 明 
configmaps 和 请 空间 中 ， 能 存在 的 ConfigMap 的 总 数 上 限 
persistentvolumeclaims 在 i 空间 中 ， 能 存在 的 持久 卷 的 总 数 上 限 
pods 在 该 命名 空间 中 ,能 存在 的 非 终 止 状态 Pod 的 总 数 上 限 。Pod 终止 状态 等 价 于 
Pod 的 status.phase 状态 值 为 Failed 或 者 Succeed is true 
命名 空间 中 ， 能 存在 的 RC 的 总 数 上 限 

















replicationcontrollers 





resourcequotas ae 空间 中 ， 能 存在 的 资源 配额 项 CResourcesQuota) 的 总 数 上 限 
services :这 空间 中 ， 能 存在 的 service 的 总 数 上 限 

services.loadbalancers Ei 空间 中 ， 能 存在 的 负载 均衡 (LoadBalancer) 的 总 数 上 限 
services.nodeports : 能 存在 的 NodePort 的 总 数 上 限 























secrets 该 命名 空间 中 ， 能 存在 的 Secret 的 总 数 上 限 








例如 我 们 可 以 通过 资源 配额 来 限制 命名 空间 中 能 创建 的 Pod 的 最 大 
数量 。 这 种 设置 可 以 防止 某 些 用 户 大 量 创 建 Pod 而 迅速 耗 尽 整个 集群 的 


Pod IP 和 计算 资源 。 
2) 配额 的 作用 域 (Quota Scopes ) 


每 项 资源 配额 都 可 以 单独 配置 一 组 作用 域 ， 配置 了 作用 域 的 资源 配 
额 只 会 对 符合 其 作用 域 的 资源 使 用 进行 计量 和 限制 ， 作 用 域 范 围 内 的 且 
超过 了 资源 配额 的 请 求 都 会 报 验证 错 。 表 5.4 列 出 了 ResourceQuota 的 4 种 
作用 域 。 


表 5.4 ”ResourceQuota 的 作用 域 


作用 域 说 A 


Terminating 匹配 所 有 spec.activeDeadlineSeconds >= 0 的 Pod 








NotTerminating JUBLATAT spec.activeDeadlineSeconds 是 mil ff) Pod 





BestEffort 匹配 所 有 QoS HW Best-Effort 的 Pod 
NotBestEffort 匹配 所 有 QoS 不 是 Best-Effort 的 Pod 














其 中 ，BestEffort 作 用 域 可 以 限定 资源 配额 来 妃 踪 pods 资 源 的 使 用 ， 
Terminating、NotTerminating 和 NotBestEffort 这 三 种 作用 域 可 以 限定 资源 
配额 来 奶 踩 以 下 资源 的 使 用 。 


e cpu 
e limits.cpu 

e limits.memory 
e memory 

e pods 

e requests.cpu 


e requests.memory 


3) 在 资源 配额 CResourceQuota) 中 设置 Requests 和 Limits 


资源 配额 也 可 以 设置 Requests 和 Limits。 


如 果 资 源 配 额 中 指定 了 requests.cpu 或 requests.memory， 那 么 它 会 强 
制 要 求 每 一 个 容 右 都 必须 配置 自己 的 CPU Requests 或 CPU Limits (可 使 
用 LimitRange 提 供 的 默认 值 ) 。 


同 理 ， 如 果 资 源 配额 中 指定 了 limits.cpu 或 limits.memory， 那 么 它 也 
会 强制 要 求 每 一 个 容器 都 必须 配置 自己 的 内 存 Requests 或 内 存 
Limits (可 使 用 LimitRange 提 供 的 默认 值 〉。 


4) 资源 配额 (ResourceQuota) 的 定义 
下 面 通过 几 个 例子 对 资源 配额 进行 设置 和 应 用 。 


与 LimitRange 相 似 ，ResourceQuota 也 设置 在 namespace 中 。 创 建 名 


为 myspace 的 namespace: 


$ kubectl create namespace myspace 


namespace "myspace" created 


创建 ResourceQuota 配 置 文件 compute-resources.yaml， 用 于 设置 计算 
资源 的 配额 : 


apiVersion: v1 
kind: ResourceQuota 
metadata: 

name: compute-resources 
spec: 


hard: 


pods: "4" 
requests.cpu: "1" 
requests.memory: 1Gi 
limits.cpu: "2" 


limits.memory: 2Gi 


创建 该 项 资源 配额 


$ kubectl create -f compute-resources.yaml --namespace=m 


resourcequota "compute-resources" created 


创建 男 一 个 名 为 object-counts.yaml 的 文件 ， 用 于 设置 对 象 数 量 的 配 
Al: 


apiVersion: v1 
kind: ResourceQuota 
metadata: 
name: object-counts 
spec: 
hard: 
configmaps: "10" 
persistentvolumeclaims: "4" 
replicationcontrollers: "20" 
secrets: "10" 
services: "10" 


services.loadbalancers: "2" 


创建 该 ResourceQuota: 


$ kubectl create -f object-counts.yaml --namespace=myspa 


resourcequota "object-counts" created 


查看 各 ResourceQuota 的 详细 信息 : 


$ kubectl describe quota compute-resources --namespace=m 


Name: compute-resources 
Namespace: myspace 

Resource Used Hard 
limits.cpu 0 2 
limits.memory 0 2Gi 

pods 0 4 
requests.cpu 0 1 
requests.memory 0 1Gi 


$ kubectl describe quota object-counts --namespace=myspa 


Name: object-counts 
Namespace: myspace 
Resource Used Hard 
configmaps 0 10 
persistentvolumeclaims 0 4 
replicationcontrollers 0 20 


secrets 1 10 


services 0 10 


services.loadbalancers 0 2 


5) 资源 配额 与 集群 资源 总 量 的 关系 


资源 配额 与 集群 资源 总 量 是 完全 独立 的 。 资 源 配额 是 通过 绝对 的 单 
位 来 配置 的 ; 这 也 就 意味 大 如 采集 群 中 新 添加 了 节点 ， 那 么 资源 配额 不 
会 目 动 更 新 ， 而 该 资源 配额 所 对 应 的 命名 空间 下 对 象 也 不 能 自动 地 增加 
资源 上 限 。 





在 茶 些 情况 下 ， 我 们 可 能 希望 资源 配额 能 文 持 更 复杂 的 策略 ， 如 下 
所 述 。 


。 对 于 不 同 的 租户 ， 按 照 比 例 划分 整个 集群 的 资源 。 

。 人 多 许 每 个 租户 都 能 按照 需要 来 提高 资源 用 量 ， 但 是 有 一 个 较 宽 容 的 
限制 ， 以 防止 意外 的 资源 耗 尽 情况 发 生 。 

。 探测 系 个 命名 空间 的 需求 ， 添 加 物理 市 点 并 扩大 资源 配额 值 。 








这 些 策略 可 以 通过 将 资源 配额 作为 一 个 控制 模块 、 手 动 编写 一 个 控 
ml (controller) 来 监控 资源 使 用 情况 ， 并 调整 命名 空间 上 的 资源 配额 
的 方式 来 实现 。 





资源 配额 将 整个 集群 中 的 资源 总 量 做 了 一 个 静态 的 划分 ， 但 它 并 没 
有 对 集群 中 的 节点 (Node) 做 任何 限制 : 不 同 命名 空间 中 的 Pod 仍 然 可 
以 运行 到 同一 个 节点 上 。 

5.ResourceQuota 和 LimitRange 实 践 指南 


根据 前 面 对 资 源 管 理 的 介绍 ， 这 里 将 通过 一 个 完整 的 例子 来 说 明 如 


何 通 过 资源 配额 和 资源 配置 范围 的 配合 来 控制 一 个 命名 空间 的 资源 使 
用 。 





集群 管理 员 根 据 集群 用 户 数 量 来 调整 集群 配置 ， 以 达到 如 下 目的 : 
能 控制 特定 命名 空间 中 的 资源 使 用 量 ， 最 终 实现 集群 的 公平 使 用 和 成 本 
的 控制 。 


需要 实现 的 功能 如 下 。 


。 限制 运行 状态 的 Pod 的 计算 资源 用 量 。 

。 限制 持久 存储 卷 的 数量 以 控制 对 存储 的 访问 。 

。 限制 负载 均衡 器 的 数量 以 控制 成 本 。 

。 防止 滥用 网 络 端 口 这 类 稀缺 资源 。 

© 提供 默认 的 计算 资源 Requests 以 便于 系统 做 出 更 优化 的 调度 。 














1) 创建 命名 空间 


创建 名 为 quota-example 的 命名 空间 ，namespace.yaml 文 件 的 内 容 如 


apiVersion: v1 
kind: Namespace 
metadata: 


name: quota-example 


$ kubectl create -f namespace. yaml 


namespace "quota-example" created 


查看 命名 空间 : 


$ kubectl get namespaces 


NAME STATUS AGE 
default Active 2m 
kube-system Active 2m 
quota-example Active 39S 


2) 设置 限定 对 象 数 目的 资源 配额 
通过 设置 限定 对 象 的 数量 的 资源 配额 ， 可 以 控制 以 下 资源 的 数量 : 


。 持久 存储 卷 ; 
。 负载 均衡 器 ; 
e NodePort。 


创建 名 为 object-counts 的 ResourceQuota: 


object-counts.yaml: 
apiversion: vi 
kind: ResourceQuota 
metadata: 
name: object-counts 
spec: 
hard: 
persistentvolumeclaims: "2" 
services.loadbalancers: "2" 


services.nodeports: "0" 


$ kubectl create -f object-counts.yaml --namespace=quota 


resourcequota "object-counts" created 


配额 系统 会 检测 到 资源 项 配额 的 创建 ， 并 且 将 会 统计 和 限制 该 命名 
空间 中 的 资源 消耗 。 


查看 该 配额 是 售 生 效 : 


$ kubectl describe quota object-counts --namespace=quota 


Name: object-counts 
Namespace: quota-example 
Resource Used Hard 
persistentvolumeclaims 0 2 
services.loadbalancers 0 2 
services.nodeports 0 O 


人 至此， 配额 系统 会 自动 阻 止 那些 使 资源 用 量 超过 资源 配额 限定 值 的 
请 求 。 


3) 设置 限定 计算 资源 的 资源 配额 


下 面 我 们 再 来 创建 一 项 限定 计算 资源 的 资源 配额 ， 以 限制 该 命名 空 
间 中 的 计算 资源 的 使 用 总 量 。 


创建 名 为 compute-resources 的 ResourceQuota: 


apiVersion: vi 
kind: ResourceQuota 


metadata: 


name: compute-resources 
spec: 
hard: 
pods: "4" 
requests.cpu: "1" 
requests.memory: 1Gi 
limits.cpu: "2" 


limits.memory: 2Gi 


$ kubectl create -f compute-resources.yaml --namespace=q 


resourcequota "compute-resources" created 


查看 该 配额 是 售 生 效 : 


$ kubectl describe quota compute-resources --namespace=q 


Name: compute-resources 
Namespace: quota-example 
Resource Used Hard 
limits.cpu 0 2 
limits.memory 0 2G1 

pods 0 4 
requests.cpu 0 1 
requests.memory 0 1Gi 








配额 系统 会 自动 防止 该 命名 空间 下 同时 拥有 超过 4 个 非 “ 终 止 态 ” 的 
Pod。 此 外 ， 由 于 该 项 资源 配额 限制 了 CPU 和 内 存 的 Limits 和 Requests 的 


总 量 ， 因 此 会 强制 要 求 该 命名 空间 下 的 所 有 容器 都 必须 显示 地 定义 CPU 
和 内 存 的 Limits 和 Requests〈 可 使 用 默认 值 ，Requests 默 认 等 于 


Limits) 。 


4) 配置 默认 Requests 和 Limits 





在 命名 空间 已 经 配置 了 限定 计算 资源 的 资源 配额 的 情况 下 ， 如 果 答 
试 在 该 命名 空间 下 创建 一 个 不 指定 Requests 和 Limits 的 Pod， 那 么 Pod 的 
创建 可 能 会 失败 。 下 面 是 一 个 失败 的 例子 。 


创建 一 个 Nginx 的 Deployment: 


$ kubectl run nginx --image=nginx --replicas=1 --namespa 


deployment "nginx" created 


查看 创建 的 Pod， 会 发 现 Pod 没 有 创建 成 功 : 


$ kubectl get pods --namespace=quota-example 


再 查看 一 下 Deployment 的 详细 信息 : 


$ kubectl describe deployment nginx --namespace=quota-ex 


Name: nginx 

Namespace: quota-example 
CreationTimestamp: Mon, 06 Jun 2016 16:11:37 -0400 
Labels: run=nginx 

Selector: run=nginx 


Replicas: 0 updated | 1 total | 0 availabl 


StrategyType: 
MinReadySeconds: 
RollingUpdateStrategy: 
OldReplicaSets: 


NewReplicaSet: 


RollingUpdate 

0 

1 max unavailable, 1 max surge 
<none> 


nginx -3137573019 (0/1 replicas c 


本 Deployment 尝 试 创建 一 个 Pod， 但 是 失败 了 ， 查 看 其 中 ReplicaSet 


的 详细 信息 : 


$ kubectl describe rs nginx-3137573019 --namespace=quota 


Name: 
Namespace: 
Image(s): 
Selector: 


Labels: 


Replicas: 
Pods Status: 
No volumes. 


Events: 


nginx -3137573019 

quota-example 

nginx 
pod-template-hash=3137573019, run 
pod-template-hash=3137573019 
run=nginx 

0 current / 1 desired 


© Running / 0 Waiting / © Succee 


FirstSeen LastSeen Count From 


{replicaset-controller } 


可 以 看 到 Pod 创 建 失败 的 原因 : Master 拒 绝 了 这 个 ReplicaSet 创 建 
Pod， 因 为 这 个 Pod 中 没有 指定 CPU 和 内 存 的 Requests 和 Limits 。 


为 了 避免 这 种 失败 ， 我 们 可 以 使 用 LimitRange 来 为 这 个 命名 空间 下 
的 所 有 Pod 提 供 一 个 资源 配置 的 默认 值 。 下 面 的 例子 展示 了 如 何 为 这 个 
命名 空间 添加 一 个 指定 默认 资源 配置 的 LimitRange。 


创建 一 个 名 为 limits 的 LimitRange: 


limits.yaml: 
apiVersion: v1 
kind: LimitRange 
metadata: 
name: limits 
spec: 
limits: 
- default: 
cpu: 200m 
memory: 512Mi 
defaultRequest: 
cpu: 100m 
memory: 256Mi 


type: Container 


$ kubectl create -f limits.yaml --namespace=quota-exampl 


limitrange "limits" created 


$ kubectl describe limits limits --namespace=quota-examp 
Name: limits 


Namespace: quota-example 


Type Resource Min Max Default Request Default 


Container memory - - 256Mi512Mi - 


Container cpu - - 100m200m - 








LimitRange 创 建成 功 后 ， 用 户 在 该 命名 空间 下 的 创建 未 指定 资源 配 
置 的 Pod 的 请 求 时 ， 系 统 会 自动 为 该 Pod 设 置 默认 的 资源 配置 。 


例如 ， 每 个 新 建 的 未 指定 资源 配置 的 Pod 都 等 价 于 使 用 下 面 的 资源 
配置 : 


$ kubectl run nginx \ 
--image=nginx \ 
--replicas=1 \ 
--requests=cpu=100m,memory=256Mi \ 
--limits=cpu=200m,memory=512Mi 和 


- -namespace=quota-example 


至 此 ， 我 们 已 经 为 该 命名 空间 配置 好 了 默认 的 计算 资源 ， 我 们 的 
ReplicaSet 应 该 能 够 创建 Pod 了 。 查 看 一 下 ， 创 建 Pod 成 功 了 : 


$ kubectl get pods --namespace=quota-example 
NAME READY STATUS RESTARTS 1 
nginx -3137573019-fvrig 1/1 Running 0 


接 下 来 ， 还 可 以 随时 碍 看 资源 配额 的 使 用 情况 : 


$ kubectl describe quota --namespace=quota-example 


Name : compute-resources 


Namespace: quota- 
Resource Used 
limits.cpu 200m 


limits.memory 512M1 
pods 1 
requests.cpu 100m 


requests.memory 256M1 


example 


Hard 


Name: object-counts 
Namespace: quota-example 
Resource Used Hard 
persistentvolumeclaims 0 2 
services.loadbalancers 0 2 


services.nodeports 


0 0 


可 以 看 到 每 个 Pod 创 建 时 都 会 消耗 掉 指 定 的 资源 量 ， 而 这 些 使 用 量 
都 会 被 Kubernetes 准 确 地 跟踪 、 监 控 和 管理 。 


5) 指定 资源 配额 的 作用 域 


假设 我 们 并 不 想 为 某 个 命名 空间 配置 默认 的 计算 资源 配额 ， 而 是 希 
望 限定 在 命名 空间 内 运行 的 QoS 为 BestEffort 的 Pod 总 数 ， 例 如 将 集群 中 
的 部 分 资源 用 来 运行 QoS 为 非 BestEffort 的 服务 ， 而 将 闲置 的 资源 用 来 运 





行 QoS 为 BestEffort 的 服务 ， 即 可 避免 集群 的 所 有 资源 仅 被 大 量 的 
BestEffort Pod 耗 尽 。 这 可 以 通过 创建 两 个 资源 配额 (ResourceQuota) 来 
实现 。 


首先 创建 一 个 名 为 quota-scopes 的 命名 空间 : 


$ kubectl create namespace quota-scopes 


namespace "quota-scopes" created 


创建 一 个 名 为 best-effort 的 ResourceQuota， 指 定 Scope 为 BestEffort: 


apiVersion: v1 
kind: ResourceQuota 
metadata: 


name: best-effort 


spec: 
hard: 
pods: "10" 
scopes: 
- BestEffort 


$ kubectl create -f best-effort.yaml --namespace=quota- si: 


resourcequota "best-effort" created 


再 创建 一 个 名 为 not-best-effort 的 ResourceQuota， 指 定 Scope 为 
NotBestEffort: 


apiVersion: v1 


kind: ResourceQuota 
metadata: 
name: not-best-effort 
spec: 
hard: 
pods: "4" 
requests.cpu: "1" 
requests.memory: 1Gi 
limits.cpu: "2" 
limits.memory: 2Gi 
scopes: 


- NotBestEffort 


$ kubectl create -f not-best-effort.yaml --namespace=quo 


resourcequota "not-best-effort" created 


查看 创建 成 功 的 ResourceQuota: 


$ kubectl describe quota --namespace=quota-scopes 
Name: best-effort 
Namespace: quota-scopes 
Scopes: BestEffort 
* Matches all pods that have best effort quality of ser 


Resource Used Hard 


Name: not-best-effort 
Namespace: quota-scopes 
Scopes: NotBestEffort 
* Matches all pods that do not have best effort quality 


Resource Used Hard 


limits.cpu 0 2 
limits.memory 0 2G1 
pods 0 4 
requests.cpu 0 1 
requests.memory 0 1Gi 


之 后 ， 对 于 没有 配置 Requests 的 Pod 将 会 被 名 为 best-effort 的 
ResourceQuota 所 限制 ， 而 配置 了 Requests 的 Pod 会 被 名 为 not-best-effort 的 
ResourceQuota 所 限制 。 


创建 两 个 Deployment: 


$ kubectl run best-effort-nginx --image=nginx --replicas: 


deployment "best-effort-nginx" created 


$ kubectl run not-best-effort-nginx \ 
--image=nginx \ 
--replicas=2 \ 
--requests=cpu=100m, memory=256Mi \ 
--limits=cpu=200m,memory=512Mi \ 


- -namespace=quota-scopes 


deployment "not-best-effort-nginx" created 


名 为 best-effort-nginx 的 Deployment 因 为 没有 配置 Requests 和 Limits， 
所 以 它 的 QoS 级 别 为 BestEffort， 因 此 它 的 创建 过 程 由 best-effort 资 源 配额 
项 来 限制 ， 而 not-best-effort 资 源 配额 项 不 会 对 它 进 行 限制 。best-effort 资 
源 配 额 项 没有 限制 Requests 和 Limits， 因 此 best-effort-nginx Deployment 可 
以 成 功 地 创建 8 个 Pod。 


名 为 not-best-effort-nginx 的 Deployment 因 为 配置 了 Requests 和 
Limits， 且 二 者 不 相等 ， 所 以 它 的 QoS 级 别 为 Burstable， 因 此 它 的 创建 
过 程 由 not-best-effort 资 源 配 额 项 来 限制 ， 而 best-effort 资 源 配 额 项 不 会 对 
它 进 行 限制 。not-best-effort 资 源 配额 项 限制 了 Pod 的 Requests 和 Limits 的 
总 上 限 ，not-best-effort-nginx Deployment 并 没有 超过 这 个 上 限 ， 所 以 可 
以 成 功 地 创建 两 个 Pod。 


查看 已 经 创建 的 Pod: 


$ kubectl get pods --namespace=quota-scopes 


NAME READY STATU: 
best-effort -nginx-3488455095-2qb41 1/1 Runni 
best-effort-nginx-3488455095-3go7n 1/1 Runni 
best-effort-nginx-3488455095-902xg 1/1 Runni 
best-effort-nginx-3488455095-eyg40 1/1 Runni 
best-effort-nginx-3488455095-gcs3v 1/1 Runni 
best-effort-nginx-3488455095-rq8p1 1/1 Runni 
best-effort-nginx-3488455095-udhhd 1/1 Runni 
best-effort-nginx-3488455095-zmk12 1/1 Runni 


not-best-effort-nginx-2204666826-7s161 1/1 Runni 





not-best-effort-nginx-2204666826-ke746 1/1 Runni 


可 以 看 到 10 个 Pod 都 创建 成 功 。 
再 看 一 下 两 个 资源 配额 项 的 使 用 情况 : 


$ kubectl describe quota --namespace=quota-scopes 


Name: best-effort 
Namespace: quota-scopes 
Scopes: BestEffort 


* Matches all pods that have best effort quality of ser 


Resource Used Hard 

pods 8 10 

Name: not-best-effort 
Namespace: quota-scopes 
Scopes: NotBestEffort 


* Matches all pods that do not have best effort quality 


Resource Used Hard 
limits.cpu 400m 2 
limits.memory 1Gi 2Gi 
pods 2 4 
requests.cpu 200m 1 


requests.memory 512Mi 1G1 


可 以 看 到 best-effort 资 源 配额 项 已 经 统计 到 了 best-effort-nginx 
Deployment 中 创建 的 8 个 Pod 的 资源 使 用 信息 ， 而 not-bestreffort 资 源 配额 
项 也 统计 到 了 not-best-effort-nginx Deployment 中 创建 的 两 个 Pod 的 资源 使 
用 信息 。 


通过 这 个 例子 我 们 可 以 看 到 : 资源 配额 的 作用 域 (Scopes) 提供 了 
一 种 将 资源 集合 分 割 的 机 制 ， 这 种 机 制 使 得 集群 管理 员 可 以 更 加 方便 地 
监控 和 限制 不 同类 型 对 象 对 于 各 类 资源 的 使 用 ， 同 时 能 为 资源 分 配 和 限 
制 提 供 更 大 的 灵活 度 和 便利 性 。 





Kubernetes 中 的 资源 管理 的 基础 是 容器 和 Pod 的 资源 配置 (Requests 
和 Limits) 。 容 器 的 资源 配置 (Requests 和 Limits) 指定 了 容器 请 求 的 资 
源 和 容器 能 使 用 的 资源 上 限 ， 而 Pod 的 资源 配置 则 是 Pod 中 所 有 容器 的 资 
源 配 置 总 和 的 上 限 。 











通过 资源 配额 (Resource Quota) 机 制 ， 我 们 可 以 对 命名 空间 下 所 
有 了 Pod 使 用 资源 的 总 量 进行 限制 ， 也 可 以 对 这 个 命名 空间 中 指定 类 型 的 
对 象 的 数量 进行 限制 。 使 用 作用 域 可 以 让 资源 配额 只 对 符合 特定 范围 的 
对 象 加 以 限制 ， 因 此 作用 域 (Scopes) 机 制 可 以 使 资源 配额 的 策略 更 加 
丰富 灵活 。 





如 果 我 们 需要 对 用 户 的 Pod 或 容器 的 资源 配置 做 更 多 的 限制 ， 则 我 
们 可 以 使 用 资源 配置 范围 〈LimitRange) 来 达到 这 个 目的 。LimitRange 
可 以 有 效 地 限制 Pod 和 容器 的 资源 配置 的 最 大 、 最 小 汽 围 ， 也 可 以 限制 
Pod 和 容器 的 Limits 与 Requests 的 最 大 比例 上 限 ， 此 外 LimitRange 还 可 以 
为 Pod 中 的 容器 提供 默认 的 资源 配置 。 





Kubernetes 基 于 Pod 的 资源 配置 (Requests 和 Limits) 实现 了 资源 服 
务 质量 (QoS) 。 不 同 QoS 级 别 的 Pod 在 系统 中 拥有 不 同 的 优先 级 : 高 优 
先 级 的 Pod 具 有 更 高 的 可 靠 性 ， 可 以 用 于 运行 可 靠 性 要 求 较 高 的 服务 ; 
而 低 优 先 级 的 Pod 可 以 实现 集群 资源 的 超 售 ， 能 有 效 地 提高 集群 资源 利 
用 率 。 





上 面 的 多 种 机 制 共同 组 成 了 当前 版 本 Kubernetes 的 资源 管理 体系 。 
这 个 资源 管理 体系 已 经 可 以 满足 大 部 分 资源 管理 的 需求 了 。 同 时 ， 
Kubernetes 资 源 管 理 体 系 仍 然 在 不 停 地 发 展 和 进化 中 ， 对 于 一 些 目前 无 
法 满足 的 更 复杂 、 更 个 性 化 的 需求 ， 我 们 可 以 继续 关注 Kubernetes 未 来 
的 发 展 和 变化 。 


5.1.5 “Kubernetes 集 群 高 可 用 部 署 方案 





Kubernetes 作 为 容器 应 用 的 管理 平台 ， 通 过 对 Pod 的 运行 状况 进行 监 
控 ， 并 且 根 据 主机 或 容器 失效 的 状态 将 新 的 Pod 调 上 度 到 其 他 Node E, K 
现 了 应 用 层 的 高 可 用 性 。 针 对 Kubernetes 集 群 ， 高 可 用 性 还 应 包含 以 下 
两 个 层面 的 考虑 : etcd 数 据 存储 的 高 可 用 性 和 Kubernetes ”Master 组 件 的 
高 可 用 性 。 


1.etcd 高 可 用 部 署 


etcd 在 整个 Kubernetes 集 群 中 处 于 中 心 数据 库 的 地 位 ， 为 保证 
Kubernetes 集 群 的 高 可 用 性 ， 首 先 需 要 保证 数据 库 不 是 单 故 障 点 。 一 方 
面 ，etcd 需 要 以 集群 的 方式 进行 部 团 ， 以 实现 etcd 数 据 存 储 的 见 余 、 备 
份 与 高 可 用 性 ; 男 一 方面 ，etcd 存 储 的 数据 本 映 也 应 考虑 使 用 可 靠 的 存 
储 设备 。 


etcd 集 群 的 部 车 可 以 使 用 静态 配置 ， 也 可 以 通过 etcd 提 供 的 REST 
API 在 运行 时 动态 添加 、 修 改 或 删除 集群 中 的 成 员 。 本 市 将 对 etcd 和 集群 
的 静态 配置 进行 说 明 。 关 于 动态 修改 的 操作 方法 请 参考 etcd 官 方 文档 的 
说 明 。 








首先 ， 规 划一 个 至 少 3 台 服务 器 (节点 ) 的 etcd 集 群 ， 在 每 台 服 务 器 
上 安装 好 etcd。 


部 署 一 个 由 3 侣 服务器 组 成 的 etcd 集 群 ， 其 配置 如 表 5.5 所 示 ， 其 集 
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etcd 实例 名 称 IP 地 址 


10.0.0.2 
10.00. 


然后 修改 每 台 服 务 器 上 etcd 的 配置 文件 /etc/etcd/etcd.conf。 





以 etcd1 为 创建 集群 的 实例 ， 需 要 将 其 


ETCD INITIAL_ CLUSTER_STATE 设 置 为 "new”。etcd1 的 完整 配置 如 
下 : 


# [member ] 


ETCD_NAME=etcd1 Het cd XHEK 





ETCD_DATA_DIR="/var/lib/etcd" ”#etcd 数 据 保存 目录 
ETCD_LISTEN_CLIENT_URLS="http://10.0.0.1:2379,http://127 
ETCD_ADVERTISE_CLIENT_URLS="http://10.0.0.1:2379,http:// 
#[cluster ] 

ETCD_LISTEN_PEER_URLS="http://10.0.0.1:2380" ”# 集 群 内 部 通 
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://10.0.0.1:2380" 
ETCD_INITIAL_CLUSTER="etcdi=http://10.0.0.1:2380, etcd2=h 
ETCD_INITIAL_CLUSTER_STATE="new" # 初 始 集群 状态 ，new 为 新 ; 
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster" ” # 集 群 名 称 


启动 etcd1l 服 务 器 上 的 etcd 服 务 : 


$ systemctl restart etcd 


启动 完成 后 ， 束 创建 了 一 个 名 为 etcd-cluster 的 集群 。 


etcd2 和 etcd3 为 加 入 etcd-cluster 和 集群 的 实例 ， 需 要 将 其 
ETCD _INITIAL _CLUSTER_STATE 设 置 为 “exist”*”。etcd2 的 完整 配置 如 
下 《etcd3 的 配置 略 ) : 


# [member ] 
ETCD_NAME=etcd2 #etcd 实 例 名 称 
ETCD_DATA_DIR="/var/lib/etcd" #etcd 数 据 保 存 目录 


ETCD_LISTEN_CLIENT_URLS="http://10.0.0.2:2379, http://127 
ETCD_ADVERTISE_CLIENT_URLS="http://10.0.0.2:2379,http:// 
#[cluster ] 

ETCD_LISTEN_PEER_URLS="http://10.0.0.2:2380" ”# 集 群 内 部 通 
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://10.0.0.2:2380" 
ETCD_INITIAL_CLUSTER="etcdi=http://10.0.0.1:2380, etcd2=h 
ETCD_INITIAL_CLUSTER_STATE="new" # 初 始 集群 状态 ，new 为 
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"  ”# 集 群 名 称 


启动 etcd2 和 etcd3 服 务 器 上 的 etcd 服 务 : 


$ systemctl restart etcd 





启动 完成 后 ， 在 任意 etcd 节 点 执行 etcdctl cluster-health 命 令 来 查询 集 
群 的 运行 状态 : 


$ etcdctl cluster-health 

cluster is healthy 

member ce2a822cea30bfca is healthy 
member acda82baicf790fc is healthy 


member eba209cd0012cd2 is healthy 


在 任意 etcd 节 点 上 执行 etcdctl member list 命令 来 查询 集群 的 成 员 列 
K: 


$ etcdctl member list 


ce2a822cea30bfca: name=default peerURLs=http://10.0.0.1: 


acda82baicf790fc: name=default peerURLs=http://10.0.0.2:: 


eba209cd40012cd2: name=default peerURLs=http://10.0.0.3:: 


至 此 ， 一 个 etcd 集 群 束 创建 成 功 了 。 
以 kube-apiserver 为 例 ， 将 访问 etcd 集 群 的 参数 设置 为 : 


--etcd-servers=http://10.0.0.1:2379,http://10.0.0.2:2379 
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考官 方 文档 的 详细 说 明 : 


https://github.com/coreos/etcd/blob/master/Documentation. 


对 于 etcd 中 需要 保存 的 数据 的 可 靠 性 ， 可 以 考虑 使 用 RAID 磁 盘 阵 
列 、 高 性 能 存储 设备 、 共 享 存储 文件 系统 ， 或 者 使 用 云 服务 商 提 供 的 存 
储 系统 等 来 实现 。 


2.Master 高 可 用 部 署 


在 Kubernetes 系 统 中 ，Master 服 务 扮演 着 总 控 中 心 的 角色 ， 主 要 的 
三 个 服务 kube-apiserver、kube-controller-mansger 和 kube-scheduler 通 过 不 
断 与 工作 节点 上 的 kubelet 和 kube-proxy 进 行 通信 来 维护 整个 集群 的 健康 
工作 状态 。 如 果 Master 的 服务 无 法 访问 到 某 个 Node， 则 会 将 该 Node 标 记 
为 不 可 用 ， 不 再 向 其 调度 新 建 的 Pod。 但 对 Master 自 身 则 需要 进行 额外 
的 监控 ， 使 Master 不 成 为 集群 的 单 故障 点 ， 所 以 对 Master 服 务 也 需要 进 
行 高 可 用 方式 的 部 署 。 


以 Master 的 kube-apiserver、kube-controller-mansger 和 kube-scheduler 
三 个 服务 作为 一 个 部 署 单元 ， 类 似 于 etcd 集 群 的 典型 部 署 配置 。 使 用 至 
少 三 台 服 务 器 安装 Master 服 务 ， 并 且 需 要 保证 任何 时 候 总 有 一 套 Master 
能 够 正常 工作 。 图 5.6 展 示 了 一 种 典型 的 部 署 方式 。 
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图 5.6 ”KubernetesMaster 高 可 用 部 署 架构 





Kubernetes 建 议 Master 的 3 个 组 件 都 以 容器 的 形式 局 动 ， 局 动 它们 的 
基础 工具 是 kubelet， 所 以 它们 都 将 以 Static Pod 的 形式 启动 并 由 kubelet 进 
行 监控 和 自动 重启 。 而 kubelet 本 身 的 高 可 用 则 通过 操作 系统 来 完成 ， 例 
如 使 用 Linux 的 Systemd 系 统 进行 管理 。 








注意 ， 如 果 之 前 已 运行 过 这 3 个 进程 ， 则 需要 先 停止 它们 ， 然 后 局 
动 kubelet 服 务 ， 这 3 个 主 进程 将 通过 kubelet 以 容器 的 形式 启动 和 运行 。 





接 下 来 分 别 对 kube-apiserver 和 kube-controller-manager、kube- 
scheduler 的 高 可 用 部 团 进 行 说 明 。 


1) kube-apiserver 的 高 可 用 部 署 


根据 第 2 章 的 介绍 ， 为 kube-apiserver 预 先 创 建 所 有 需要 的 CA 证 书 和 
基本 鉴 权 文件 等 内 容 ， 然 后 在 每 台 服 务 器 上 创建 其 日 志文 件 : 


# touch /var/log/kube-apiserver.log 


假设 kubelet 的 启动 参数 指定 --config=/etckubernetes/manifests， 即 
Static ”Pod 定 义 文件 所 在 的 目录 ， 接 下 来 就 可 以 创建 kube-apiserver.yaml 
配置 文件 用 于 启动 kube-apiserver J - 








kube-apiserver.yaml 
apiversion: v1 
kind: Pod 
metadata: 
name: kube-apiserver 
spec: 
hostNetwork: true 
containers: 
- name: kube-apiserver 
image: gcr.io/google_containers/kube-apiserver :9680e782e 
command: 
- /bin/sh 
- -C 
- /usr/local/bin/kube-apiserver --etcd-servers=http: 
--admission-control=NamespaceLifecycle, LimitRanger, Secur 


--service-cluster-ip-range=169.169.0.0/16 --v=2 


--allow-privileged=False 1>>/var/log/kube-apiserve 

ports: 

- containerPort: 443 
hostPort: 443 
name: https 

- containerPort: 7080 
hostPort: 7080 
name: http 

- containerPort: 8080 
hostPort: 8080 
name: local 

volumeMounts: 

- mountPath: /srv/kubernetes 
name: srvkube 
readOnly: true 

- mountPath: /var/log/kube-apiserver.log 
name: logfile 

- mountPath: /etc/ssl 
name: etcssl 
readOnly: true 

- mountPath: /usr/share/ssl 
name: usrsharessl 
readOnly: true 

- mountPath: /var/ssl 
name: varssl 
readOnly: true 


- mountPath: /usr/ssl 


name: usrssl 
readOnly: true 
- mountPath: /usr/lib/ssl 
name: usrlibssl 
readOnly: true 
- mountPath: /usr/local/openssl 
name: usrlocalopenssl 
readOnly: true 
- mountPath: /etc/openssl 
name: etcopenssl 
readOnly: true 
- mountPath: /etc/pki/tls 
name: etcpkitls 
readOnly: true 
volumes: 
- hostPath: 
path: /srv/kubernetes 
name: srvkube 
- hostPath: 
path: /var/log/kube-apiserver.log 
name: logfile 
- hostPath: 
path: /etc/ssl 
name: etcssl 
- hostPath: 
path: /usr/share/ssl 


name: usrsharessl 


- hostPath: 
path: /var/ssl 
name: varssl 
- hostPath: 
path: /usr/ssl 
name: usrssl 
- hostPath: 
path: /usr/lib/ssl 
name: usrlibssl 
- hostPath: 
path: /usr/local/openssl 
name: usrlocalopenssl 
- hostPath: 
path: /etc/openssl 
name: etcopenssl 
- hostPath: 
path: /etc/pki/tls 


name: etcpkitls 


其 中 ， 


。 kube-apiserver 需 要 使 用 hostNetwork 模 式 ， 即 直接 使 用 宿主 机 网 络 ， 
以 使 得 客户 端 能 够 通过 物理 机 访问 其 API。 

。 镜像 的 tag 来 源 于 kubernetes 发 布 包 中 的 kube-apiserver.docker_tag 文 
件 : kubernetes/server/kubernetes-server-linux-amd64/server/bin/kube- 
apiserver.docker_tag. 


e --etcd-servers: 指定 etcd 服 务 的 URL 地 址 。 


。 再 加 上 其 他 必要 的 启动 参数 ， 包 括 --admission-control、--service- 
cluster-ip-range、CA 证 书 相 关 配 置 等 内 容 。 

。 端口 号 的 设置 都 配置 了 hostPort， 将 容 堪 内 的 端口 号 直接 映射 为 体 
主机 的 端口 号 。 





将 kube-apiserver.yaml 文 件 复 制 到 kubelet 监 控 
的 /etckubernetes/manifests 目 录 下 ，kubelet 将 会 自动 创建 yaml 文 件 中 定义 
的 kube-apiserver 的 Pod。 


接 下 来 在 另外 两 台 服 务 器 上 重复 该 操作 ， 使 得 每 台 服 务 器 上 都 局 动 


一 个 kube-apiserver 的 Pod。 
2) 为 kube-apiserver 配 置 负载 均衡 器 


至 此 ， 我 们 启动 了 三 个 kube-apiserver 实 例 ， 这 三 个 kube-apiserver 都 
可 以 正常 工作 ， 我 们 需要 一 个 统一 的 、 可 靠 的 、 人 允许 部 分 Master 节 点 故 
障 的 方式 来 访问 它们 ， 可 以 通过 部 署 一 个 负载 均衡 器 来 实现 。 








在 不 同 的 平台 下 ， 负 和 载 均衡 的 实现 方式 不 同 : 在 一 些 公 用 云 比如 
GCE、AWS、 阿 里 云 上 都 有 现成 的 实现 方案 ， 对 于 本 地 集群 ， 我 们 可 
以 选择 人 硬件 或 者 软件 来 实现 负载 均衡 ， 比 如 Kubernetes 社 区 推荐 的 方案 
haproxy 和 keepalived 来 实现 ， 其 中 haproxy 做 负载 均衡 ， 而 keepalived 负 
贡 对 haproxy 监 控 和 进行 高 可 用 。 





在 完成 API Server 的 负载 均衡 配置 之 后 ， 对 其 访问 还 需要 注意 以 下 


内 容 。 


。 如 宁 Master 开 司 了 安全 认证 机 制 ， 那 么 瑚 要 确保 证 书 中 包含 负载 均 
衡 服务 节点 的 卫 。 


e 对 于 外 部 的 访问 ， 比 如 通过 kubectl 访 问 API Server， 那 么 需要 配置 
为 访问 API Server 对 应 的 负载 均衡 器 的 IP 地 址 。 


3) kube-controller-manager 和 kube-scheduler 的 高 可 用 配置 


不 同 于 API Server，Master 中 另外 两 个 核心 组 件 kube-controller- 
manager 和 kube-scheduler 会 修改 集群 的 状态 信息 ， 因 此 对 于 kube- 
controller-manager 和 kube-scheduler 而 言 ， 高 可 用 不 仅 意 味 着 需要 局 动 多 
个 实例 ， 还 需要 这 多 个 实例 能 实现 选举 并 选举 出 leader， 以 保证 同一 时 
间 只 有 一 个 实例 可 以 对 集群 状态 信息 进行 读 写 ， 避 免 出 现 同 步 问 题 和 一 
致 性 问题 。Kubernetes 对 于 这 种 选举 机 制 的 实现 是 采用 租赁 锁 〈lease- 
lock) 来 实现 的 ， 我 们 可 以 通过 在 kube-controller-manager 和 kube- 
scheduler 的 每 个 实例 的 启动 参数 中 设置 --leader-elect=true， 来 保证 同一 
时 间 只 会 运行 一 个 可 修改 集群 信息 的 实例 。 








Scheduler 和 Controller Manager 高 可 用 的 具体 实现 方式 如 下 。 


首先 在 每 个 Master 节 点 上 创建 相应 的 日 志文 件 : 


# touch /var/log/kube-scheduler.1og 


# touch /var/log/kube-controller-manager.1og 


然后 创建 kube-controller-manager 和 kube-scheduler 的 Pod 定 义 文件 : 


kube-controller-manager .yaml: 
apiVersion: v1 
kind: Pod 


metadata: 


name: kube-controller-manager 


spec: 


hostNetwork: true 


containers: 


- name: kube-controller -manager 


image: gcr.io/google_containers/kube-controller-mana 


command: 


/bin/sh 
-C 
/usr/local/bin/kube-controller-manager --master=12 


--v=2 --leader-elect=true 1>>/var/log/kube-control 


livenessProbe: 


httpGet: 

path: /healthz 

port: 10252 
initialDelaySeconds: 15 


timeoutSeconds: 1 


volumeMounts: 


mountPath: /srv/kubernetes 

name: srvkube 

readOnly: true 

mountPath: /var/log/kube-controller-manager .log 
name: logfile 

mountPath: /etc/ssl 

name: etcssl 

readOnly: true 


mountPath: /usr/share/ssl 


name: usrsharessl 
readOnly: true 
- mountPath: /var/ssl 
name: varssl 
readOnly: true 
- mountPath: /usr/ssl 
name: usrssl 
readOnly: true 
- mountPath: /usr/lib/ssl 
name: usrlibssl 
readOnly: true 
- mountPath: /usr/local/openssl 
name: usrlocalopenssl 
readOnly: true 
- mountPath: /etc/openssl 
name: etcopenssl 
readOnly: true 
- mountPath: /etc/pki/tls 
name: etcpkitls 
readOnly: true 
volumes: 
- hostPath: 
path: /srv/kubernetes 
name: srvkube 
- hostPath: 
path: /var/log/kube-controller-manager.log 


name: logfile 


N 
4 


hostPath: 

path: /etc/ssl 
name: etcssl 
hostPath: 

path: /usr/share/ssl 
name: usrsharessl 
hostPath: 

path: /var/ssl 
name: varssl 
hostPath: 

path: /usr/ssl 
name: usrssl 
hostPath: 

path: /usr/lib/ssl 
name: usrlibssl 
hostPath: 

path: /usr/local/openssl 
name: usrlocalopenssl 
hostPath: 

path: /etc/openssl 
name: etcopenssl 
hostPath: 

path: /etc/pki/tls 


name: etcpkitls 


kube-controller-manager 需 要 使 用 hostNetwork 模 式 ， 即 直接 使 用 宿 
机 网 络 。 
镜像 的 tag 来 源 于 kubernetes 发 布 包 中 的 kube-controller- 


manager.docker tag 文件 : kubernetes/server/kubernetes-server-linux- 


amd64/server/bin/kube-controller-manager.docker_tag. 
--master: 指定 kube-apiserver 服 务 的 URL 地 址 。 
--leader-elect=true: 使 用 leader 选 举 机 制 |。 


kube-scheduler.yaml: 
apiVersion: v1 
kind: Pod 
metadata: 
name: kube-scheduler 
spec: 
hostNetwork: true 
containers: 


- name: kube-scheduler 


image: gcr.io/google_containers/kube-scheduler : 34d0b8f 8b. 


command: 
- /bin/sh 


- -C 


- /usr/local/bin/kube-scheduler --master=127.0.0.1: 


livenessProbe: 
httpGet: 
path: /healthz 
port: 10251 


initialDelaySeconds: 15 


y 


Æ 


8| 


timeoutSeconds: 1 
volumeMounts: 
- mountPath: /var/log/kube-scheduler.log 
name: logfile 
- mountPath: /var/run/secrets/kubernetes.io0/servicea 
name: default-token-s8ejd 
readOnly: true 
volumes: 
- hostPath: 
path: /var/log/kube-scheduler.log 


name: logfile 


其 中 ， 


e kube-scheduler 需 要 使 用 hostNetwork 模 式 ， 即 直接 使 用 宿主 机 网 
络 。 

。 镜像 的 tag 来 源 于 kubernetes 发 布 包 中 的 kube-scheduler.docker_tag 文 
件 : kubernetes/server/kubernetes-server-linux-amd64/server/bin/kube- 
scheduler.docker tag。 

e --master: 指定 kube-apiserver 服 务 的 URL 地 址 。 

e --leader-elect=true: 使 用 leader 选 举 机 制 |。 


将 这 两 个 yaml 文 件 复制 到 kubelet 监 控 的 /etckubernetes/manifests 目 录 
下 ，kubelet 将 会 自动 创建 yaml 文 件 中 定义 的 kube-controller-manager 和 
kube-scheduler 的 Pod。 


至 此 ， 我 们 完成 了 Kubernetes _ Master 组 件 高 可 用 的 完整 配置 ， 配 合 
etcd 存 储 的 高 可 用 ， 整 个 Kubernetes 集 群 的 高 可 用 已 经 全 部 完成 。 最 





后 ， 只 需要 确认 集群 中 所 有 访问 API Server 的 地 方 都 已 经 将 访问 地 址 修 
改 为 负载 均衡 的 地 址 ， 就 可 以 保证 集群 高 可 用 的 正 稼 工作 了 。 


3.Master 高 可 用 架构 的 演进 


在 当前 的 版 本 中 ，kubelet 可 以 设置 “--api-servers” 启 动 参数 来 指定 多 
个 kube-apiserver， 但 是 当 第 1 个 kube-apiserver 不 可 用 之 后 ，kubelet 无 法 
连接 到 后 面 的 kube-apiserver， 也 就 是 说 只 有 第 1 个 kube-apiserver 起 作 
用 。 如 果 这 个 问题 得 到 解决 ， 则 kubelet 无 须 通 过 额外 的 负载 均衡 器 就 能 
连接 到 多 个 API Server 了。 


另外 ， 除 了 kubelet， 其 他 核心 组 件 kube-controller-manager、kube- 
scheduler 和 kube-proxy 都 需要 配置 kube-apiserver， 目 前 它们 的 启动 参数 “- 
-master 仅 支持 配置 一 个 kube-apiserver， 还 无 法 支持 多 个 kube-apiserver 
的 配置 。 


Kubernetes 计 划 在 后 续 的 版 本 中 支持 多 个 Master 的 配置 ， 实 现 不 需 
要 负载 均衡 器 的 Master 高 可 用 架构 。 


5.1.6 ”Kubernetes 集 群 监控 


1. 通 过 cAdvisor 页 面 查看 容器 的 运行 状态 


开源 软件 cAdvisor (Container Advisor) 是 用 于 监控 容器 运行 状态 的 
利器 之 一 《cAdvisor 项 目的 主页 为 https://github.com/google/cadvisor) ， 
它 被 用 于 多 个 与 Docker 相 关 的 开源 项 目 中 。 


在 Kubernetes 系 统 中 ，cAdvisor 已 被 默认 集成 到 了 kubelet 组 件 内 ， 当 
kubelet 服 务 启 动 时 ， 它 会 自动 启动 cAdvisor 服 务 ， 然 后 cAdvisor 会 实时 
采集 所 在 节点 的 性 能 指标 及 在 节点 上 运行 的 容器 的 性 能 指标 。kubelet 的 
局 动 参数 --cadvisor-port 可 自 定 义 cCAdvisor 对 外 提供 服务 的 端口 号 ， 默 认 
为 4194。 








cAdvisor 提 供 了 Web 页 面 可 供 浏 览 嚣 访问。 例如 Kubernetes 集 群 中 的 
一 个 Node 的 IP 地 址 是 192.168.18.3， 则 在 浏览 器 中 输入 网 址 
http://192.168.18.3: 4194 来 访问 cAdvisor 的 监控 页 面 。cAdvisor 的 主页 显 
示 了 主机 的 实时 运行 状态 ， 包 括 CPU 使 用 情况 、 内 存 使 用 情况 、 网 络 吞 
吐 量 及 文件 系统 使 用 情况 等 信 


图 5.7 展 示 了 cAdvisor 的 几 个 性 能 监控 页 面 。 
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图 5.7 主机 的 性 能 监控 页 面 





通过 Docker Containers 链 接 可 以 查看 容器 列表 及 每 个 容器 的 性 能 数 
据 ， 如 网 5.8 所 示 。 
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图 5.8 容 需 的 性 能 监控 页 面 


此 外 ，cAdvisor 也 提供 了 REST API 供 客户 端 远程 调用 ， 主 要 是 为 了 
定制 开发 ，API 返 回 的 数据 格式 为 JSON， 可 以 采用 如 下 URL 来 访问 : 


http://<hostname>:<port>/api/<version>/<request> 


例如 ， 通 过 URL http://192.168.18.3: 4194/api/v1.3/machine 可 以 获取 
主机 的 相关 信息 : 


"num_cores":2, 
"cpu_frequency_khz":2793544, 


"memory _capacity":1915408384, 
"machine_id":"0f6233d8256a4ec1a673640e04b8344a", 


"system_uuid":"564D188F -8E82-21C0-6E89-176E2C51EBB5" 


"boot_id":"a03d00d8 -ca9c-4d74-a674-ebf5dfbc69d9", 


"filesystems": [ 


{ 


"device":"/dev/mapper/rhel-root", 


"Capacity":18746441728 


"device":"/dev/sdai", 


"Capacity":520794112 


], 
"disk_map": { 
"253:0":{ 
"name":"dm-0", 
"major":253, 


"minor":0, 


"size":2147483648, 


"scheduler":"none" 


ty 
Sy 
"network_devices": [ 
{ 
"name": "eno16777736", 
"mac_address":"00:0c:29:51:eb:b5", 
"speed":1000, 
"mtu" :1500 
} 
], 
"topology": [ 
{ 


"node_id":0, 

"memory" :2146947072, 

"cores": [ 

{ 
"core_id":0, 
"thread_ids": [ 
0 

], 


"caches":null 


], 


"caches":[ 


{ 
"size":6291456, 
"type":"Unified", 
"level" :3 

} 


通过 下 面 的 URL 则 可 以 获取 市 点 上 最 新 (1 分 钟 内 〉 的 容 占 的 性 能 
数据 : http://192.168.1.129: 
4194/api/v1.3/subcontainers/system.slice/docker- 
5015d5c7ef72b98627332fabd031251cbd3f191418500f7aec6b9950399661ed.: 


HRN: 


{ 
"name":"/system.slice/docker -5015d5c7ef72b98627332fabd03 


"aliases": [ 
"k8s_master.f8a6f6df_Redis-master-6o0kig_default_9c428d4f 
"5015d5c7ef 72b98627332fabd031251cbd3f191418500f 7aec6b9951 

], 

"namespace":"docker", 


"spec": { 


"creation_time" :"2015-08-17T08:44:27.4011225 
"labels": { 


"10.kubernetes.pod.name":"default/Redis-|! 


ty 

"has_cpu": true, 

"Cpu": { 
"Limit":2, 


"max_limit":0, 
"mask":"0-1" 

ty 

"has_memory":true, 

"memory": { 
"Limit":18446744073709552000, 
"swap_limit":18446744073709552000 

ty 

"has_network":true, 

"has_filesystem":false, 


"has _diskio":true 


ty 
"stats": [ 
{ 
"timestamp":"2015-08-18T00:54:26.1679885 
"Cpu": { 
"usage": { 


"total" :43121463207, 
"ner_cpu_usage": [ 


21578091763, 


21543371444 
], 
"user'":410000000, 
"system": 13620000000 


ty 
"load_average":0 
ty 
"diskio":{ 


"10 _service_bytes":[ 
{ 
"major":253, "minor":14, 
"stats": { 


"Async" : 8036352, "Read": 8036352, "Sync":0, "Total" : 8036352, 


} 
} 
], 
"i0_serviced":[ 
{ 
"major" :8, 
"minor":0, 
"stats": { 
"Async":0, 
] 
ty 
"memory": { 


"usage":16748544, 


"working set":9297920, 

"container_data":{ 
"ogfault":882, 
"pgmajfault":8 

ty 

"hierarchical_data": { 
"ogfault":882, 


"ogmajfault":8 


ty 
"network": { 
"name":"", 

"rx_bytes":0,"rx_packets":0,"rx_errors":0,"rx_dropped":0 

ty 

"task_stats":{ 
"nr_sleeping":0,"nr_running":0, '"nr_stopped":0, "nr_uninte 

} 

ty 


容器 的 性 能 数据 对 于 集群 监控 非常 有 用 ， 系 统管 理 员 可 以 根据 
cAdvisor 提 供 的 数据 进行 分 析 和 告警 。 不 过 ， 由 于 cAdvisor 是 在 每 台 
Node 上 运行 的 ， 只 能 采集 本 机 的 性 能 指标 数据 ， 所 以 系统 管理 员 需 要 对 
每 台 Node 主 机 单独 监控 。 


针对 大 型 集群 ，Kubernetes 建 议 使 用 几 个 开源 软件 组 成 的 集成 解决 
方案 来 实现 对 整个 集群 的 监控 。 这 些 开源 软件 包括 Heapster、InfluxDB 
及 Grafana 等 。 





2.Heapster+Influxdb+Grafana 集 群 性 能 监控 平台 搭建 


根据 前 面 的 说 明 ，cAdvisor 和 集成 在 kubelet 中 ， 运 行 在 每 个 Node 上 ， 
所 以 一 个 cAdvisor 仪 能 对 一 台 Node 进 行 监控 。 在 大 规模 容器 集群 中 ， 需 
要 对 所 有 Node 和 全 部 容器 进行 性 能 监控 ，Kubermetes 建 议 使 用 一 套 工具 
来 实现 集群 性 能 数据 的 采集 、 存 储 和 展示 : Heapster、InfluxDB 和 


Grafana。 


e Heapster: 对 集群 中 各 Node 上 cAdvisor 的 数据 采集 汇聚 的 系统 ， 通 
过 访问 每 个 Node 上 kubelet 的 API， 再 通过 kubelet 调 用 CAdvisor 的 API 
来 采集 该 节点 上 所 有 容器 的 性 能 数据 。Heapster 对 性 能 数据 进行 聚 
合 ， 并 将 结果 保存 到 后 端 存储 系统 中 。Heaspter 文 持 多 种 后 端 人 存储 
系统 ， 包 括 memory 〈 保 存在 内 存 中 ) 、IfluxDB、BigQuery、 谷 歌 
云 平 台 提 供 的 Google Cloud 
Monitoring (https://cloud.google.com/monitoring/) 和 Google Cloud 
Logging (https://cloud.google.com/logging/) 等 。Heapster 项 目的 主 
页 为 https://github.com/kubernetes/heapster。 

。 InfluxDB: 是 分 布 式 时 序数 据 库 “〈 每 条 记录 都 带 有 时 间 惟 属性 ) ， 
主要 用 于 实时 数据 采集 、 事 件 跟踪 记录 、 存 储 时 间 图 表 、 原 始 数 据 
等 。InfluxDB 提 供 了 REST API 用 于 数据 的 存储 和 查询 。InfluxDB 的 
主页 为 http://influxdb.com。 

e Grafana: 通过 Dashboard 将 InfluxDB 中 的 时 序数 据 展现 成 图 表 或 曲 
线 等 形式 ， 便 于 运 维 人 员 奏 看 集群 的 运行 状态 。Grafana 的 主页 为 














http://grafana.org。 


基于 heapster+influxdb+grafana 的 集群 监控 系统 总 体 架构 如 图 5.9 所 
示 。 
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图 5.9 ”Heapster 集 群 监控 系统 架构 图 


Heapster、InfluxDB 和 Grafana 均 以 Pod 的 形式 启动 和 运行 。 由 于 
Heapster 需 要 与 Kubernetes Master 进 行 安全 连接 ， 所 以 需要 设置 Master 的 
CA 证 书 安全 策略 〈 参 见 第 2 章 的 说 明 ) 。 





1) 部 署 Heapster、InfluxDB、Grafana 容 器 应 用 
先 创建 它们 的 Service: 
heapster-service.yaml 


apiVersion: v1 


kind: Service 


metadata: 


labels: 


kubernetes.io/cluster-service: 


kubernetes.io/name: Heapster 
name: heapster 


namespace: kube-system 


spec: 
ports: 
- port: 80 
targetPort: 8082 
selector: 


k8s-app: heapster 


influxdb-service.yaml 


apivVersion: v1 
kind: Service 
metadata: 
labels: null 
name: monitoring-InfluxDB 
namespace: kube-system 
spec: 


type: NodePort 


ports: 
- name: http 
port: 8083 


targetPort: 8083 


"true" 


nodePort: 8083 
- name: api 
port: 8086 
targetPort: 8086 
nodePort: 8086 
selector: 


name: influxGrafana 


注意 ， 这 里 使 用 type=NodePort 将 InfluxDB 暴 露 在 宿主 机 Node 的 端口 
上 ， 以 便 我 们 使 用 浏览 器 对 其 进行 访问 。 


grafana-service.yaml 


apiversion: v1 
kind: Service 
metadata: 
labels: 
kubernetes.io/name: monitoring-Grafana 
kubernetes.io/cluster-service: "true" 
name: monitoring-Grafana 
namespace: kube-system 
spec: 
type: NodePort 
ports: 
- port: 80 
targetPort: 8080 
nodePort: 8085 


selector: 


name: influxGrafana 


ARE, 1 Ftype=NodePort’ Grafanaze E Node im OE, MEZ 
户 端的 浏览 器 对 其 进行 访问 。 


使 用 kubectl create 命 令 创 建 Services: 


$ kubectl create -f heapster-service.yaml 
$ kubectl create -f InfluxDB-service.yaml 


$ kubectl create -f Grafana-service.yaml 


在 创建 heapster 容 器 之 前 ， 先 创建 InfluxDB 和 Grafana 的 RC， 这 两 个 
容器 将 运行 在 同一 个 Pod 中 : 


influxdb-grafana-controller-v3.yaml 


apivVersion: vi 
kind: ReplicationController 
metadata: 
name: monitoring-influxdb-grafana-v3 
namespace: kube-system 
labels: 
k8s-app: influxGrafana 
version: v3 
kubernetes.io/cluster-service: "true" 
spec: 


replicas: 1 


selector: 
k8s-app: influxGrafana 
version: v3 
template: 
metadata: 
labels: 
k8s-app: influxGrafana 
version: v3 
kubernetes.io/cluster-service: "true" 
spec: 
containers: 
- image: gcr.io/google_containers/heapster_influ 
name: influxdb 
resources: 
# keep request = limit to keep this containe 
limits: 
cpu: 100m 
memory: 500Mi 
requests: 
cpu: 100m 
memory: 500Mi 
ports: 
- containerPort: 8083 
- containerPort: 8086 
volumeMounts: 
- name: influxdb-persistent-storage 


mountPath: /data 


image: gcr.i0/google_containers/heapster_grafa 
name: grafana 
resources: 
limits: 
cpu: 100m 
memory: 100Mi 
requests: 
cpu: 100m 
memory: 100Mi 
env: 
# This variable is required to setup templati 
- name: INFLUXDB_SERVICE_URL 
value: http://monitoring-influxdb: 8086 
# The following env variables are required 
# the kubernetes api-server proxy. On prod 
# removing these env variables, setup auth 
# service using a LoadBalancer or a public 
- name: GF_AUTH_BASIC_ENABLED 
value: "false" 
- name: GF_AUTH_ANONYMOUS_ENABLED 
value: "true" 
- name: GF_AUTH_ANONYMOUS_ORG_ROLE 
value: Admin 
- name: GF_SERVER_ROOT_URL 
value: /api/vi/proxy/namespaces/kube-systel 
volumeMounts: 


- name: grafana-persistent-storage 


mountPath: /var 
volumes: 
- name: influxdb-persistent-storage 
emptyDir: {} 
- name: grafana-persistent-storage 


emptyDir: {} 


注意 ，Grafana 容 器 环境 变量 INFLUXDB_SERVICE_URL 设 置 为 
InfluxDB 服 务 的 所 在 地 址 。 由 于 Grafana 与 InfluxDB 人 处 于 同一 个 Pod 中 ， 
所 以 Grafana 使 用 127.0.0.1 或 localhost 也 可 以 访问 到 InfluxDB 服 务 。 


使 用 kubectl create 命 令 创建 该 RC: 


$ kubectl create -f influxdb-grafana-controller-v3.yaml 


通过 kubectl get pods--namespace=kube-system 确 认 Pod 成 功 启动 : 


# kubectl get pods --namespace=kube-system 
NAME READY S 


monitoring-influxdb-grafana-v3-uu730 2/2 Running 


创建 heapster 容 器 ，v1.1.0 版 本 的 heapster 由 4 个 容器 组 合 为 一 个 
Pod: 


heapster-controller-v1.1.0.yaml 


apiVersion: extensions/vibeta1l 


kind: Deployment 


metadata: 
name: heapster-v1.1.0 
namespace: kube-system 
labels: 
k8s-app: heapster 
kubernetes.io/cluster-service: "true" 
version: v1.1.0 
spec: 
replicas: 1 
selector: 
matchLabels: 
k8s-app: heapster 
version: v1.1.0 
template: 
metadata: 
labels: 
k8s-app: heapster 
version: v1.1.0 
spec: 
# 4 containers, 2 heapsters, 2 resizer 
containers: 
- image: gcr.io/google_containers/heapster:v1i.1. 
name: heapster 
resources: 
# keep request = limit to keep this containe 
limits: 


cpu: 100m 


memory: 200Mi 
requests: 
cpu: 100m 
memory: 200Mi 
command: 
- /heapster 
- --source=kubernetes.summary_api:'192.168.1 
- --Sink=influxdb:http://monitoring-influxdb 
- --metric_resolution=60s 
- image: gcr.io/google_containers/heapster:v1i.1. 
name: eventer 
resources: 
# keep request = limit to keep this containe 
limits: 
cpu: 100m 
memory: 200Mi 
requests: 
cpu: 100m 
memory: 200Mi 
command: 
- /eventer 
- --source=kubernetes: '192.168.18.3:8080' 
- --Sink=influxdb:http://monitoring-influxdb 
- image: gcr.io/google_containers/addon-resizer: 
name: heapster -nanny 
resources: 


limits: 


cpu: 50m 
memory: 100Mi 
requests: 
cpu: 50m 
memory: 100Mi 
env: 
- name: MY_POD_NAME 
valueFrom: 
fieldRef: 
fieldPath: metadata.name 
- name: MY_POD_NAMESPACE 
valueFrom: 
fieldRef: 


fieldPath: metadata.namespace 


command: 
- /pod_nanny 
- --cpu=100m 


- --extra-cpu=0m 
- --memory=200M1 
- --extra-memory=4Mi 
- --threshold=5 
- --deployment=heapster-v1.1.0 
- --container=heapster 
- --poll-period=300000 
- --estimator=exponential 
image: gcr.io/google_containers/addon-resizer:: 


name: eventer-nanny 


resources: 
limits: 
cpu: 50m 
memory: 100Mi 
requests: 
cpu: 50m 
memory: 100Mi 
env: 
- name: MY_POD_NAME 
valueFrom: 
fieldRef: 
fieldPath: metadata.name 
- name: MY_POD_NAMESPACE 
valueFrom: 
fieldRef: 


fieldPath: metadata.namespace 


command: 
- /pod_nanny 
- --cpu=100m 


- --extra-cpu=0m 

- --memory=200M1 

- --extra-memory=500Ki 

- --threshold=5 

- --deployment=heapster-v1.1.0 
- --container=eventer 

- --poll-period=300000 


- --estimator=exponential 


Heapster 需 要 设置 的 启动 参数 如 下 。 
(1) -source 


配置 采集 来 源 ， 为 Master URL 地 址 : 


--source=kubernetes.summary_api: '192.168.18.3:8080' 


(2) -sink 
配置 后 端 存储 系统 ， 使 用 InfluxDB 系 统 : 


--Sink=InfluxDB:http://monitoring-InfluxDB:8086 


(3) --metric resolution 





性 能 指标 的 精度 ，60s 表 示 将 过 去 60 秒 的 数据 进行 汇聚 再 进行 存 
储 。 


其 他 参数 可 以 通过 进入 heapster 容 器 执行 抽 eapster--help 命 令 查 看 和 
设置 。 


注意 ，URL 中 的 主机 名 地 址 使 用 的 是 InfluxDB 的 Service 名 字 ， 这 和 需 
要 DNS 服务 正常 工作 ， 如 果 没 有 配置 DNS 服务 ， 则 也 可 以 使 用 Service 的 
ClusterIP 地 址 。 





值得 说 明 的 是 ，InfluxDB 服 务 的 名 称 没有 加 上 命名 空间 ， 是 因为 
Heapster 服 务 与 InfluxDB 服 务 属于 相同 的 命名 空间 kube-system。 当 然 ， 
使 用 带 上 命名 空间 的 全 服务 名 也 是 可 以 的 ， 例 如 http://monitoring- 


influxdb.kube-system: 8086. 


使 用 kubectl create 


人 人心， 
命令 完 


成 创建 该 RC: 


$ kubectl create -f heapster-controller-v1.1.0.yaml 


通过 kubectl get pods--namespace=kube-system fff À Pod BMI a 5) : 


# kubectl get deployment --namespace=kube-system 


NAME 


READY STATUS 


heapster-v1.1.0-1895667918-guisl 4/4 Running 


查看 heapster 的 日 志 ， 确 保 heapster 成 功 在 influxdb 数 据 库 中 创建 名 为 


k8s 的 数据 库 : 


# kubectl logs 


I0706 
I0706 
I0706 
I0706 
I0706 
I0706 
I0706 
I0706 


2) 查询 InfluxDB 数 据 库 中 的 数据 


09: 
09: 
09: 
09: 
09: 
09: 
09: 
09: 


36: 
36: 
36: 
36: 
36: 
36: 
36: 
36: 


15. 
15. 
15. 
15. 
15. 
15. 
15. 
16. 


heapster-v1.1.0-1895667918-guisl -c heaps 


313587 
313849 
314347 
314371 
512107 
512154 
512163 
414060 


E e E EBE EBE EBE B B 


heapster.go:65] /heapster 

heapster.go:66] Heapster v 
configs.go:60] Using Kuber 
configs.go:61] Using kubel 
influxdb.go:223] created i 
heapster.go:92] Starting w 
heapster.go:92] Starting w 


heapster.go:171] Starting 


让 我 们 先 通过 InfluxDB 的 管理 页 面 查 看 数据 。 


由 于 设置 mmfluxDB 服 务 会 暴露 到 物理 Node 节 点 上 ， 所 以 我 们 可 以 通 
过 任 一 Node 的 8083 端 口 访问 InfluxDB 数 据 库 提 供 的 管理 页 面 ， 如 图 5.10 
所 示 。 通 过 右上 角 齿 轮 按钮 可 以 修改 连接 属性 (用 于 influxdb service 设 
置 为 非 默认 端口 号 的 时 候 ) 。 单 击 右上 角 的 Database 下 拉 列 表 可 以 选择 
数据 库 ，heapster 创 建 的 数据 库 名 为 k8s。 


3X Influx 





图 5.10 InfluxDB 管 理 页 面 


在 Query 输 入 框 中 输入 “SHOW _ MEASUREMENTS”， 即 可 查看 所 有 
的 measurements 〈 序 列表 ) 。 图 5.11 显 示 了 部 分 measurements 。 





Influx 





Query Templates ~ 


measurements 
name 





图 5.11 show measurements 结 果 页 面 


heapster 采 集 的 全 部 metric《〈 性 能 指标 ) 如 表 5.6 所 示 。 


表 5.6 ”heapster 采 集 的 metric 


metric 名 称 





cpu/limit 


CPU hard limit， 单 位 为 毫秒 





cpu/node_reservation 


Node 保留 的 CPU Share 





cpu/node_utilization 


Node 的 CPU 使 用 时 间 





cpu/request 


CPU request， 单 位 为 毫秒 





cpu/usage 


全 部 Core 的 CPU 累计 使 用 时 间 





cpu/usage_rate 


全 部 Core 的 CPU 崇 计 使 用 率 ， 单 位 为 毫秒 





filesystem/usage 


文件 系统 已 用 的 空间 ， 单 位 为 字 节 





filesystem/limit 


文件 系统 总 空间 限制 ， 单 位 为 字 节 





filesystem/available 


文件 系统 可 用 的 空间 ， 单 位 为 字 节 





memory/limit 


Memory hard limit， 单 位 为 字 节 





memory/major_page_faults 


major page faults 数量 





memory/major_page faults _rate 


每 秒 的 major page faults 数量 





memory/node_reservation 


Node 保留 的 内 存 Share 





memory/node_utilization 


Node 的 内 存 使 用 值 





memory/page_faults 


page faults 数量 





memory/page_faults_rate 


metric 名 称 





每 秒 的 page faults 数量 





memory/request 


Memory request， 单 位 为 字 节 





memory/usage 


总 内 存 使 用 量 





memory/working_ set 


总 的 Working set usage, Working set 是 指 不 会 被 kernel 移 除 的 内 存 





network/rx 


计 接 收 的 网 络 流量 字 节 数 





network/rx_errors 


崇 计 接收 的 网 络 流量 错误 数 





network/rx_errors_rate 


每 秒 接收 的 网 络 流量 错误 数 





network/rx_rate 


每 秒 接收 的 





network/tx 


计 发 送 的 





network/tx_errors 


计 发 送 的 网 络 流量 错误 数 





network/tx_errors_rate 


秒 发 送 的 网 络 流量 错误 数 





network/tx_rate 








每 秒 发 送 的 网 络 流量 字 节 数 





uptime 








容器 启动 总 时 长 








每 个 metric 可 以 看 作 一 张 数据 库 表 ， 表 中 每 条 记录 由 一 组 label 组 
成 ， 可 以 看 作 字段 ， 如 表 5.7 所 示 。 


表 5.7 metric 的 各 label 


Label 名 称 
pod id 系统 生成 的 Pod 唯一 名 称 
pod_name 用 户 指定 的 Pod 名 称 














pod_namespace Pod 所 属 的 namespace 





container_base_image 容器 的 镜像 名 称 








container name 户 指定 的 容器 名 称 
host id 户 指定 的 Node 主机 名 


hostname 容器 运行 所 在 主机 名 























labels 逗号 分 隔 的 Label 列表 








namespace id Pod 所 属 的 namespace 的 UID 











resource_id 资源 ID 


可 以 使 用 标准 SQL SELECT 语句 对 每 个 metric 进 行 查 询 ， 例 如 查询 
CPU 的 使 用 时 间 : 


select * from "Cpu/usage" limit 10 


结果 如 图 5.12 所 示 。 


cpu/usage 


value 





图 5.12 ”查询 cpuusage 结 果 页 面 


3) Grafana 页 面 查 看 和 操作 


访问 Grafana 服 务 需 要 通过 Master 代 理 模 式 进 行 访问 ，URL 地 址 为 
http://192.168.18.3: 8080/api/v1/proxy/namespaces/kube- 


system/services/monitoring-grafana/. 





在 grafana 主 页 可 以 查看 监控 数据 的 图 表 展 示 画 面 。 如 图 5.13 所 示 为 
Cluster 集 群 的 整体 信息 ， 以 折线 图 的 形式 展示 了 集群 范围 内 各 Node 的 
CPU 使 用 率 、 内 存 使 用 情况 等 信息 。 





图 5.13 Grafana Cluster 监 控 页 面 








图 5.14 显 示 的 是 所 有 Pod 的 信息 ， 以 折线 图 的 形式 展示 了 集群 范围 
内 各 Pod 的 CPU 使 用 率 、 内 存 使 用 情况 、 网 络 流量 、 文 件 系统 使 用 情况 


人 
S| 局 





图 5.14 Grafana Pod 监 控 页 面 


Grafana 页 面 上 的 每 个 图 表 都 可 以 进行 编辑 ， 在 标题 上 单 击 鼠标 ， 
点 击 “Edit* 进 入 编辑 页 面 ， 可 以 对 每 个 metric 进 行 个 性 化 设置 ， 例 如 查询 
的 表 名 、 字 段 名 、 汇 总 计算 等 ， 如 图 5.15 所 示 。 











图 5.15 ”编辑 折线 图 


到 此 ， 基 于 heapster+influxdb+grafana 的 Kubernetes 集 群 监控 系统 就 
搭建 完成 了 。 


5.1.7 ”kubelet 的 垃圾 回收 CGC) 机 制 


Kubernetes 集 群 中 的 垃圾 回收 (Garbage Collection, faj#KGC) 机制 
由 kubelet 完 成 。kubelet 定 期 清理 不 再 使 用 的 容器 和 镜像 ， 每 分 钟 进行 一 
次 容器 GC 操作 ， 每 5 分 钟 进行 一 次 镜像 GC 操作 。 


1. 容 器 (Container) 的 GC 设置 


能 够 被 GC 清理 的 容器 只 能 是 仅 由 kubelet 管 理 的 容器 。 在 kubelet 所 
在 的 Node 上 直接 通过 docker run 创 建 的 容器 将 不 会 被 kubelet 进 行 GC 清理 
操作 。 


kubelet 的 以 下 3 个 启动 参数 用 于 设置 容器 GC 的 条 件 。 


e --minimum-container-ttl-duration: 已 停止 的 容器 在 被 清理 之 前 的 最 
小 存活 时 间 ， 例 如 “300ms”10s” 或 “2h45m”， 超 过 此 存活 时 间 的 容 
器 将 被 标记 为 可 被 GC 清理 ， 默 认 值 为 1 分 钟 。 

e --maximum-dead-containers-per-container: 以 Pod 为 单位 的 可 以 保留 
的 已 停止 的 〈 属 于 同一 Pod 的 ) 容器 集 的 最 大 数量 。 有 时 ，Pod 中 容 
器 运行 失败 或 者 健康 检查 失败 后 ， 会 被 kubelet 上 自动 重 局， 这 将 产生 
一 些 停止 的 容器 。 默 认 值 为 2。 

e --maximum-dead-containers: 在 本 Node 上 保留 的 已 停止 容器 的 最 大 
数量 ， 由 于 停止 的 容器 也 会 消耗 磁盘 空间 ， 所 以 超过 该 上 限 以 后 ， 
kubelet 会 自动 清理 已 停止 的 容器 以 释放 磁盘 空间 ， 默 认 值 为 240。 














如 果 需 要 关闭 针对 容器 的 GC 操 作 ， 则 可 以 将 --minimum-container- 
ttl-duration 设 置 为 0， 将 --maximum-dead-containers-per-container 和 -- 


maximum-dead-containers 设 置 为 负数 。 


2. 镜 像 (Image) 的 GC 设置 
ah 


ZN 


Kubernetes 系 统 中 通过 imageController 和 kublet 中 集成 的 cAdvisor 
同 管理 镜像 的 生命 周期 ， 主 要 根据 本 Node 的 磁盘 使 用 率 来 触发 镜像 的 
GC 操 作 。 
kubelet 的 以 下 3 个 局 动 参数 用 于 设置 镜像 GC 的 条 件 。 
。 --minimum-image-ttl-duration: 不 再 使 用 的 镜像 在 被 清理 之 前 的 最 小 
存活 时 间 ， 例 如 *300ms”“10s” 或 “2h45m”， 超 过 此 存活 时 间 的 镜像 


被 标记 为 可 被 GC 清 理 ， 默 认 值 为 两 分 钟 。 
e --image-gc-high-threshold: 当 磁 盘 使 用 率 达 到 该 值 时 ， 和 触发 镜像 的 


GC 操作 ， 默 认 值 为 900%。 
e --image-gc-low-threshold: 当 磁 盘 使 用 率 降 到 该 值 时 ，GC 操 作 结 


束 ， 默 认 值 为 80%。 
删除 镜像 的 机 制 为 : 当 磁 盘 使 用 率 达 到 image-gc-high-threshold H 
如 90%) 时 触发 ， GC 操作 从 最 久未 使 用 (Least Recently Used) 的 镜像 
开始 删除 ， 直 到 磁盘 使 用 率 降 为 image-gc-low-threshold (例如 80%) 或 


没有 镜像 可 删 为 止 。 


5.2 Kubernetes 高 级 案例 


本 节 将 对 ElasticSearch 日 志 管 理 平 台 的 部 晋 、Cassandra 集 群 的 部 署 
及 Kubernetes 中 容器 的 高 级 应 用 进行 说 明 。 





5.2.1 ElasticSearch 日 志 搜 集 碍 询 和 展现 案例 


在 Kubernetes 集 群 环境 中 ， 一 个 完整 的 应 用 或 服务 都 会 涉及 为 数 众 
多 的 组 件 运行 ， 各 组 件 所 在 的 Node 及 实例 数量 都 是 可 变 的 。 日 志 子 系统 
如 有 果 不 做 集中 化 管理 ， 则 会 给 系统 的 运 维 文 撑 造 成 很 大 的 困难 ， 因 此 有 
必要 在 集群 层面 对 日 志 进 行 统一 的 收集 和 检索 等 工作 。 


容器 中 输出 到 控制 台 的 日 志 ， 都 会 以 *-json.log 的 命名 方式 保存 
在 /var/ib/docker/containers/ 目 录 之 下 ， 这 样 束 给 了 我 们 进行 日 志 采 和 集 和 
后 续 处 理 的 基础 。 


Kubernetes 推 荐 采用 Fluentd+ElasticSearch+Kibana 完 成 对 日 志 的 采 
集 、 查 询 和 展现 工作 。 


在 部 晋 系 统 之 前 ， 需 要 以 下 两 个 前 提 条 件 。 
e API Server 正 确 配置 了 CA 证 书 。 
e DNS 服务 启动 运行 。 

1. 系 统 部 署 架 构 

系统 的 逻辑 架构 如 图 5.16 所 示 。 


在 各 Node 上 运行 一 个 Fluentd 容 器 ， 对 本 节点 /var/log 
和 /varvlib/dockercontainers 两 个 目录 下 的 日 志 进 程 采 集 ， 然 后 汇总 到 
ElasticSearch 集 群 ， 最 终 通 过 Kibana 完 成 和 用 户 的 交互 工作 。 





这 里 有 一 个 特殊 的 需求 ，Fluentd 必 须 在 每 个 Node 上 运行 一 份 ， 为 
了 满足 这 一 需要 ， 我 们 有 以 下 几 种 不 同 的 方式 来 部 署 Fluentd。 





。 直接 在 Node 主 机 上 部 署 Fluentd。 
e 利用 kubelet 的 --config 参 数 ， 为 每 个 Node 加 载 Fluentd Pod. 
e 利用 DaemonSet 来 让 FluentdPod 在 每 个 Node 上 运行 。 





mo 


Elastic 集群 





| /var/lib/docker/containers | 





NodeA 


ee | 











索引 和 查询 








| /var/lib/docker/containers | 
NodeB 








图 5.16 ”Fluentd+ElasticSearch+Kibana 系 统 逻 辑 架 构图 
目前 官方 推荐 的 包括 Fluentd、Logstash 等 日 志 或 者 监控 类 的 Pod 的 
运行 方式 就 是 DaemonSet 方 式 ， 因 此 本 节 我 们 也 以 这 一 方式 进行 配置 。 
2. 创 建 ElasticSearch RC 和 Service 


ElasticSearchł RCH Service Œ X : 


elasticsearch-rc-svc.yml 
apiVersion: v1 


kind: ReplicationController 


metadata: 
name: elasticsearch-logging-v1i 
namespace: kube-system 
labels: 
k8s-app: elasticsearch-logging 
version: v1 
kubernetes.io/cluster-service: "true" 
spec: 
replicas: 2 
selector: 
k8s-app: elasticsearch-logging 
version: v1 
template: 
metadata: 

labels: 
k8s-app: elasticsearch-logging 
version: v1 
kubernetes.io/cluster-service: "true" 

spec: 

containers: 

- image: gcr.i0/google_containers/elasticsearch:1.‘ 
name: elasticsearch-logging 
resources: 

# keep request = limit to keep this container 
limits: 
cpu: 100m 


requests: 


cpu: 100m 
ports: 
- containerPort: 9200 
name: db 
protocol: TCP 
- containerPort: 9300 
name: transport 
protocol: TCP 
volumeMounts: 
- name: es-persistent-storage 
mountPath: /data 
volumes: 
- name: es-persistent-storage 
emptyDir: {} 
apivVersion: v1 
kind: Service 
metadata: 
name: elasticsearch-logging 
namespace: kube-system 
labels: 
k8s-app: elasticsearch-logging 
kubernetes.io/cluster-service: "true" 
kubernetes.io/name: "Elasticsearch" 
spec: 
ports: 


- port: 9200 


protocol: TCP 
targetPort: db 
selector: 


k8s-app: elasticsearch-logging 


执行 kubectl create-f elastic-search.yml 命 令 完 成 创建 。 





命令 成 功 执行 后 ， 首 先 验证 Pod 的 运行 情况 。 通 过 kubectl get pods-- 
namespaces=kube-system 获 取 运 行 中 的 Pod: 


# kubectl get pods --namespaces=kube-system 


NAMESPACE NAME READ" 
kube-system elasticsearch-logging-v1-59qvp 1/1 
kube-system elasticsearch-logging-v1i-xnv1i4 1/1 


接 下 来 通过 ElasticSearch 的 页 面 验证 其 功能 。 
4.47 #kubectl cluster-info 命 令 获 取 ElasticSearch 服 务 的 地 址 : 


# kubectl cluster-info 


Elasticsearch is running at http://192.168.18.3:8080/api 


接 下 来 使 用 #ubect] proxy 命 令 对 apiserver 进 行 代理 ， 成 功 执行 后 和 输 
出 如 下 : 


# kubectl proxy 
Starting to serve on 127.0.0.1:8001 


这 样 我 们 就 可 以 在 浏览 器 上 访问 URL 地 址 http://192.168.18.3: 
8001/api/v1/proxy/namespaces/kube-system/services/elasticsearch-logging , 
来 验证 ElasticSearch 的 运行 情况 了 ， 返 回 的 内 容 是 一 个 JSON 文 档 : 


{ 

"status": 200, 

"name": "Emplate", 

"cluster_name": "kubernetes-logging", 


"version": { 

"number": "1.5.2", 

"build_hash": "62ff9868b4c8a0c45860bebb259e219807 78abic" 
"build_timestamp": "2015-04-27T09:21:06Z", 


"build snapshot": false, 


"lucene_version": "4.10.4" 
}, 
"tagline": "You Know, for Search" 


} 


3. 在 每 个 Node 上 启动 Fluentd 


Fluentd 的 DaemonSet 定 义 如 下 : 


fluentd-ds.yml 
apiVersion: extensions/vibetal 
kind: DaemonSet 


metadata: 


name: fluentd-cloud-logging 
namespace: kube-system 
labels: 


k8s-app: fluentd-cloud-logging 


spec: 
template: 
metadata: 
namespace: kube-system 
labels: 
k8s-app: fluentd-cloud-logging 
spec: 


containers: 

- name: fluentd-cloud-logging 
image: gcr.io/google_containers/fluentd-elastics: 
resources: 

limits: 
cpu: 100m 
memory: 200Mi 
env: 

- name: FLUENTD_ARGS 
value: -q 

volumeMounts: 

- name: varlog 
mountPath: /var/log 
readOnly: false 

- name: containers 


mountPath: /var/lib/docker/containers 


readOnly: false 
volumes: 
- name: containers 
hostPath: 
path: /var/lib/docker/containers 
- name: varlog 
hostPath: 


path: /var/log 


通过 kubectl create fir 4 @!] Fluentd Z 4s: 


# kubectl create -f fluentd-ds.yml 


查看 创建 的 结果 : 


# kubectl get daemonset 


NAME DESIRED CURRENT 


fluentd-cloud-logging 3 3 


# kubectl get pods 


NAMESPACE NAME READY 
fluentd-cloud-logging-7tw9z 1/1 
fluentd-cloud-logging-aqdn1 1/1 
fluentd-cloud-logging-o4usx 1/1 





NODE -SELI 


<none> 


STATUS 
Running 
Running 


Running 


结果 显示 Fluentd ”DaemonSet 正 常 运 行 ， 启 动 3 个 Pod， 与 集群 中 的 


Node 数 量 一 致 。 


接 下 来 ， 使 用 四 ubectl logsfluentd-cloud-logging-7tw9z 命 令 查看 Pod 
的 日 志 ， 在 ElasticSearch 正 党 工作 的 情况 下 ， 我 们 会 看 到 类 似 下 面 这 样 
的 Ele Iù 容 : 


# kubectl logs fluentd-cloud-logging-7tw9z 


Connection opened to Elasticsearch cluster => {:host=>"e 


说 明 Fluentd 与 ElasticSearch 已 经 正确 建立 了 连接 。 


4. 运 行 Kibana 


到 此 我 们 已 经 运行 了 ElasticSearch 和 Fluentd， 数 据 的 采集 和 汇聚 过 
程 已 经 完成 ， 接 下 来 就 是 使 用 Kibana 来 展示 和 操作 数据 了 。 


Kibana 的 RC 和 Service 定 义 如 下 : 


kibana-rc-svc.yml 
apiversion: v1 
kind: ReplicationController 
metadata: 
name: kibana-logging-v1i 
namespace: kube-system 
labels: 
k8s-app: kibana-logging 
version: v1 


kubernetes.io/cluster-service: "true" 


spec: 
replicas: 1 
selector: 
k8s-app: kibana-logging 
version: v1 
template: 
metadata: 
labels: 
k8s-app: kibana-logging 
version: v1 
kubernetes.io/cluster-service: "true" 
spec: 
containers: 
- name: kibana-logging 
image: gcr.io/google_containers/kibana:1.3 
resources: 
# keep request = limit to keep this container 
limits: 
cpu: 100m 
requests: 
cpu: 100m 
env: 
- name: "ELASTICSEARCH_URL" 
value: "http://elasticsearch-logging:9200" 
ports: 
- containerPort: 5601 


name: ui 


protocol: TCP 
apiversion: vi 
kind: Service 
metadata: 
name: kibana-logging 
namespace: kube-system 
labels: 
k8s-app: kibana-logging 
kubernetes.io/cluster-service: "true" 
kubernetes.io/name: "Kibana" 
spec: 
ports: 
- port: 5601 
protocol: TCP 
targetPort: ui 
selector: 


k8s-app: kibana-logging 


通过 kubectl ”create-f ”kibana-rc-svc.yml 命 令 创 建 Kibana 的 RC 和 


Service: 


# kubectl create -f kibana-rc-svc.yml 
replicationcontroller "kibana-logging-vi" created 


service "kibana-logging" created 


查看 Kibana 的 运行 情况 : 


# kubectl get pods 





NAMESPACE NAME READY STATU: 

default kibana-logging-v1i-o1akg 1/1 Running 

# kubectl get svc 

NAME CLUSTER- IP EXTERNAL - IP PORT 

kibana-logging 169.169.195.177 <none> 5601/T 

# kubectl get rc 

NAME DESIRED CURRENT AGE 

kibana-logging-v1 1 1 1h 
结果 表明 运行 均 已 成 功 。 通 过 kubectl cluster-info 命 令 获 取 Kibana 服 

务 的 URL 地 址 : 


# kubectl cluster-info 


Kibana is running at http://127.0.0.1:8080/api/v1/proxy/ 


同样 通过 kubectl proxy 命 令 局 动 代理 ， 在 出 现 Starting to serve on 
127.0.0.1: 8001 字 样 之 后 ， 用 浏览 器 访问 URL 地 址 即 可 访问 Kibana 页 面 


了 : http://192.168.18.3: 8001/api/v1/proxy/namespaces/kube- 


system/services/kibana-logging - 





第 1 次 进入 页 面 需 要 进行 一 些 设置 ， 如 图 5.17 所 示 ， 选 择 所 需 
后 单 击 create。 
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图 5.17 


Kibana 创 建 索 引 页 面 





然后 单 击 discover， 就 可 以 正常 查询 日 志 了 ， 如 图 5.18 所 示 。 
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图 5.18 ”Kibana 查 询 日 志 页 面 


搜索 栏 输 入 “error” 关 键 字 ， 可 以 搜索 出 从 某 些 Node 上 找到 的 日 志 
记录 ， 如 图 5.19 所 示 。 
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图 5.19 Kibana 日 志 关 键 字 搜索 页 
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5.2.2 Cassandra 集 群 部 署 案例 


Apache Cassandra 是 一 套 开 源 分 布 式 NoSQL 数 据 库 系 统 ， 其 主要 特 
点 就 是 它 不 是 单个 数据 库 ， 而 是 由 一 组 数据 库 节 点 共同 构成 的 一 个 分 布 
式 的 集群 数据 库 。 由 于 Cassandra 使 用 的 是 “去 中 心 化 ”模式 ， 所 以 当 集 群 
里 的 一 个 节点 启动 之 后 需要 一 个 途径 获知 集群 中 新 节点 的 加 入 。 
Cassandra 使 用 了 Seed 种子) 的 概念 来 完成 在 集群 中 节点 之 间 的 相互 得 
找 和 通信 。 





本 例 通 过 对 Kubernetes 中 Service 概 念 的 巧妙 使 用 实现 了 各 Cassandra 
节点 之 间 的 相互 查找 。 


1. 自 定义 SeedProvider 





在 本 例 中 使 用 了 一 个 自 定义 的 SeedProvider 类 来 完成 新 节点 的 查询 
和 添加 ， 类 名 为 io.k8s.cassandra.KubernetesSeedProvider。 


KubernetesSeedProvider.java 类 的 源 代 人 码 节 选 如 下 : 


public List<InetAddress> getSeeds() { 
List<InetAddress> list = new ArrayList<InetAddre 
String host = "https://kubernetes.default.cluste 
String serviceName = getEnvOrDefault("CASSANDRA_SERVICE" 


String podNamespace = getEnvOrDefault("POD_NAMES| 


String path = String.format("/api/vi/namespaces/' 
public static void main(String[] args) { 
SeedProvider provider = new KubernetesSeedProvidi 


System.out.println(provider.getSeeds()); 


完整 的 源 代码 可 以 从 这 里 获取 : 


http://kubernetes.io/v1.0/examples/cassandra/java/src/io/k8s/cassandra/Kuberı 
创建 Cassandra Pod 的 配置 文件 如 下 : 


cassandra.yaml 


apiversion: v1 
kind: Pod 
metadata: 
labels: 
name: cassandra 
name: cassandra 
spec: 
containers: 
- args: 
- /run.sh 
resources: 
limits: 


cpu: "0.5" 


image: gcr.1i0/google_containers/cassandra:v5 
name: cassandra 
ports: 
- name: cql 
containerPort: 9042 
- name: thrift 
containerPort: 9160 
volumeMounts: 
- name: data 
mountPath: /cassandra_data 
env: 
- name: MAX_HEAP_SIZE 
value: 512M 
- name: HEAP_NEWSIZE 
value: 100M 
- name: POD_NAMESPACE 
valueFrom: 
fieldRef: 
fieldPath: metadata.namespace 
volumes: 
- name: data 


emptyDir: {} 


需要 说 明 的 是 ， 在 镜像 gcr.io/google_containers/cassandra: v5 中 安装 
了 一 个 标准 的 Cassandra 应 用 程序 ， 并 将 定制 的 SeedProvider 类 一 一 
KubernetesSeedProvider 打 包 到 镜像 中 了 。 


定制 的 KubernetesSeedProvider 类 将 使 用 REST _ API 来 访问 Kubernetes 
Master， 然 后 通过 查询 name=cassandra 的 服务 指向 的 Pod 来 完成 对 其 
他 “节点 ”的 查找 。 


2. 通 过 Service 动 态 查 找 Pod 





在 KubernetesSeedProvider 类 中 ， EN 
CASSANDRA_SERVICE 的 值 来 获得 服务 的 名 称 。 这 样 就 要 求 Service 需 
要 在 Pod 之 前 创建 出 来 。 如 果 我 们 已 经 创建 好 DNS 服务 (参见 5.1 节 的 案 
例 介 绍 ) ， 那 么 也 可 以 直接 使 用 服务 的 名 称 而 无 须 使 用 环境 变量 。 


回顾 一 下 Service 的 概念 。Service 通 常用 作 一 个 负载 均衡 器 ， 供 
Kubernetes 集 群 中 其 他 应 用 (Pod) 对 属于 该 Service 的 一 组 Pod 进 行 访 
问 。 由 于 Pod 的 创建 和 销毁 都 会 实时 更 新 Service 的 Endpoints 数 据 ， 所 以 
可 以 动态 地 对 Service 的 后 端 Pod 进 行 查询 了 。Cassandra 的 “去 中 心 化 ” 设 
计 使 得 Cassandra 和 集群 中 的 一 个 Cassandra 实 例 ( 节 点 ) 只 需要 查询 到 其 
他 节点 ， 即 可 自动 组 成 一 个 集群 ， 正 好 可 以 使 用 Service 的 这 个 特性 查询 

到 新 增 的 节点 。 图 5.21 描 述 了 Cassandra 新 节点 加 入 集群 的 过 程 。 





[| 


Kubernetes | 
Master 











2. 获取 Service 的 
后 端 Endpoint， 将 
新 Pod 加 入 集群 






















2. 获取 Service 的 
后 端 Endpoint， 将 
新 Pod 加 入 和 集群 


Cassandra 
Node 
1. 新 节点 的 出 现 ， 

将 更 新 Service 的 
Cassandra Endpoint 
Node 


S J 


74 
—— 、 i NEW 
Cassandra — = Cassandra | 
Node \ Node / 


、 7 
` 7 
h fi 六 ‘id 











图 5.21 Cassandra 新 节点 加 入 集群 的 过 程 
在 Kubernetes 系 统 中 ， 首 先 需 要 为 Cassandra 集 群 定义 一 个 Service。 


cassandra-service.yaml: 


apiVersion: v1 
kind: Service 
metadata: 

labels: 

name: cassandra 

name: cassandra 
spec: 

ports: 


- port: 9042 


selector: 


name: cassandra 


在 Service 的 定义 中 指定 Label Selector Yname=cassandra. 


(1) 创建 Service: 


$ kubectl create -f cassandra-service.yaml 


(2) 创建 一 个 Cassandra Pod: 


$ kubectl create -f cassandra-pod.yaml 


现在 ， 一 个 名 为 cassandra 的 Pod 运 行 起 来 了 ， 但 还 没有 组 成 
Cassandra 集 群 。 


(3) 创建 一 个 RC 来 控制 Pod 集 群 : 
cassandra-controller.yaml 


apiVersion: v1 
kind: ReplicationController 
metadata: 
labels: 
name: cassandra 
name: cassandra 
spec: 


replicas: 1 


selector: 
name: cassandra 
template: 
metadata: 
labels: 
name: cassandra 
spec: 
containers: 
- command: 
- /run.sh 
resources: 
limits: 
cpu: 0.5 
env: 
- name: MAX_HEAP_SIZE 
value: 512M 
- name: HEAP_NEWSIZE 
value: 100M 
- name: POD_NAMESPACE 
valueFrom: 
fieldRef: 
fieldPath: metadata.namespace 
image: gcr.i0/google_containers/cassandra:v5 
name: cassandra 
ports: 
- containerPort: 9042 


name: cql 


- containerPort: 9160 
name: thrift 
volumeMounts: 
- mountPath: /cassandra_data 
name: data 
volumes: 
- name: data 


emptyDir: {} 


由 于 在 RC 定义 中 指定 的 replicas 数 量 为 1， 所 以 创建 RC 后 ， 仍 然 只 
有 之 前 创建 的 那个 名 为 cassandra 的 Pod 在 运行 。 


3.Cassandra 集 群 中 新 节点 的 上 自动 添加 


现在 ， 我 们 使 用 Kubernetes 提 供 的 Scale“〈 动 态 缩放 ) 机 制 对 
Cassandra 集 群 进行 扩容 : 


$ kubectl scale rc cassandra --replicas=2 


查看 Pod， 可 以 看 到 RC 创建 并 启动 了 一 个 新 的 Pod: 


$ kubectl get pods -1="name=cassandra" 


NAME READY STATUS RESTARTS AGE 
cassandra 1/1 Running 0 5m 
cassandra-g52t3 1/1 Running 0 50s 


使 用 Cassandra 提 供 的 nodetool 工 具 对 任 一 cassandra 实 例 (Pod) 进行 


访问 来 验证 Cassandra 集 群 的 状态 。 下 面 的 命令 将 访问 名 为 cassandra 的 
Pod (访问 cassandra-g52t3 也 能 获得 相同 的 结果 〉: 


$ kubectl exec -ti cassandra -- nodetool status 


Datacenter: datacenter1 


Status=Up/Down 


|/ State=Normal/Leaving/Joining/Moving 


-- Address Load Tokens Owns (effective) Hos 
UN 10.1.20.16 51.58 KB 256 100.0% 162! 
UN 10.1.10.11 51.51 KB 256 100.0% cdf! 


可 以 看 到 Cassandra 集 群 中 有 两 个 节点 处 于 正常 运行 状态 (Up and 
Normal, UN) 。 结 果 中 的 两 个 IP 地 址 为 两 个 Cassandra Pod 的 IP 地 址 。 


内 部 的 过 程 为 : 每 个 Cassandra 节 点 〈Pod) 通过 API 访 问 Kubernetes 
Master， 和 碍 询 名 为 cassandra 的 Service 的 Endpoints〈 即 Cassandra 节 点 ) ， 
若 发 现 有 新 节点 加 入 ， 束 进行 添加 操作 ， 最 后 成 功 组 成 了 一 个 Cassandra 
集群 。 


我 们 再 增加 两 个 Cassandra 实 例 : 


$ kubectl scale rc cassandra --replicas=4 


用 nodetool 工 具 查 看 Cassandra 集 群 状态 : 


$ kubectl exec -ti cassandra -- nodetool status 


Datacenter: datacenter1 


Status=Up/Down 


|/ State=Normal/Leaving/Joining/Moving 


UN 


Address 


10.1.20. 
10.1.10. 
10.1.20. 
10.1.10. 


16 
12 
17 
11 


Load Tokens Owns (effective) Hos 
51.58 KB 256 50.5% 162! 
52.03 KB 256 47.0% 8bc 
68.05 KB 256 50.6% 579| 
51.51 KB 256 51.9% cdf 


可 以 看 到 4 个 Cassandra 节 点 都 加 入 Cassandra 集 群 中 了 。 


另外 ， 可 以 通过 查看 Cassandra Pod 的 日 志 来 看 到 新 节点 加 入 集群 的 
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$ kubectl logs 
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cassandra-g52t3 


Handshaking version with /10.1.20.17 

Node /10.1.20.17 is now part of the clusti 
InetAddress /10.1.20.17 is now UP 
Handshaking version with /10.1.10.12 

Node /10.1.10.12 is now part of the clusti 


InetAddress /10.1.10.12 is now UP 


本 例 描述 了 一 种 通过 API 查 询 Service 来 完成 动态 Pod 发 现 的 应 用 场 
景 。 对 于 类 似 于 Cassandra 集 群 的 应 用 ， 都 可 以 使 用 对 Service 进 行 查 询 后 
端 Endpoints 这 种 巧妙 的 方法 来 实现 对 应 用 集群 〈 属 于 同一 Service) 中 新 
加 入 节点 的 查找 。 





5.3 Trouble Shooting 指导 


本 节 将 对 Kubernetes 集 群 中 稼 见 的 问题 的 排查 方法 进行 说 明 。 





为 了 跟踪 和 发 现 Kubernetes 集 群 中 运行 的 容器 应 用 出 现 的 问题 ， 管 
用 的 查 错 方法 如 下 。 





首先 ， 查 看 Kubernetes 对 象 的 当前 运行 时 信息 ， 特 别 是 与 对 象 关 联 
的 Event 事 件 。 这 些 事件 记录 了 相关 主题 、 发 生 时 间 、 最 近 发 生 时 间 、 
发 生 次 数 及 事件 原因 等 ， 对 排查 故障 非常 有 价值 。 此 外 ， 通 过 得 看 对 象 
的 运行 时 数据 ， 我 们 还 可 以 发 现 参数 错误 、 关 联 错误 、 状 态 异 党 等 明显 
问题 。 由 于 Kubernetes 中 多 种 对 象 相互 天 联 ， 因 此， 这 一 步 可 能 会 涉及 
多 个 相关 对 象 的 排查 问题 。 








其 次 ， 对 于 服务 、 容 器 的 问题 ， 则 可 能 需要 深入 容器 内 部 进行 故障 
诊断 ， 此 时 可 以 通过 查看 容器 的 运行 日 志 来 定位 具体 问题 。 














最 后 ， 对 于 某 些 复杂 问题 ， 比 如 Pod 调 度 这 种 全 局 性 的 问题 ， 可 能 
需要 结合 集群 中 每 个 节点 上 的 Kubernetes 服 务 日 志 来 排查 。 比 如 搜集 
Master 上 kube-apiserver、kube-schedule、kube-controler-manager 服 务 的 日 
志 ， 以 及 各 个 Node 节 点 上 的 kubelet、kube-proxy 服 务 的 日 志 ， 毕 合 判断 
各 种 信息 ， 我 们 就 能 找到 问题 的 原因 并 解决 问题 。 


5.3.1 查看 系统 Event 事 件 


在 Kubernetes 集 群 中 创建 了 Pod 之 后 ， 我 们 可 以 通过 kubectl get pods 
命令 查看 Pod 列 表 ， 但 该 命令 能 够 显示 的 信息 很 有 限 。Kubernetes 提 供 了 
kubectl describe pod 命 令 来 查看 一 个 Pod 的 详细 信息 。 





$ kubectl describe pod redis-master-bobr0 


Name: Redis-master -bobro 
Namespace: default 
Image(s): kubeguide/Redis-master 
Node: k8s-node-1/192.168.18.3 
Labels: name=Redis-master, role=m 
Status: Running 
Reason: 
Message: 
IP: 172.17.0.58 
Replication Controllers: Redis-master (1/1 replici 
Containers: 
master: 
Image: kubeguide/Redis -master 
Limits: 
cpu: 250m 
memory: 64Mi 


State: Running 


Started : Fri, 21 Aug 2015 14:45:37 +0800 


Ready: True 
Restart Count: 0 
Conditions: 
Type Status 
Ready True 
Events: 
FirstSeen LastSeen Count Fri 
Fri, 21 Aug 2015 14:45:36 +0800 Fri, 21 Aug 2015 
Fri, 21 Aug 2015 14:45:37 +0800 Fri, 21 Aug 2015 
Fri, 21 Aug 2015 14:45:37 +0800 Fri, 21 Aug 2015 
Fri, 21 Aug 2015 14:45:37 +0800 Fri, 21 Aug 2015 
Fri, 21 Aug 2015 14:45:37 +0800 Fri, 21 Aug 2015 
Fri, 21 Aug 2015 14:45:37 +0800 Fri, 21 Aug 2015 





该 命令 除了 显示 Pod 创 建 时 的 配置 定义 、 状 态 等 信息 ， 还 显示 了 与 
该 Pod 相 关 的 最 近 的 Event 事 件 ， 事 件 信息 对 于 碍 错 非 常 有 用 。 如 果 某 个 
Pod 一 直 处 于 Pending 状 态 ， 则 我 们 通过 kubectl describe S mife T AESI 
失败 的 具体 原因 。 例 如 ， 从 Event 事 件 中 我 们 可 能 获知 Pod 失 败 的 原因 有 
以 下 几 种 。 








。 没有 可 用 的 Node 以 供 调度 。 
。 开启 了 资源 配额 管理 并 且 当 前 Pod 的 目标 节点 上 恰好 没有 可 用 的 资 
。 正在 下 载 镜像 。 





kubectl describe 命 令 还 可 用 于 查看 其 他 Kubernetes 对 象 ， 包 括 


Node、RC、Service、Namespace、Secrets 等 ， 对 于 每 一 种 对 象 都 


相关 联 的 其 他 信息 。 


例如 ， 查 看 一 个 服务 的 详细 信息 : 


$ kubectl describe service redis-master 


Name: 
Namespace: 
Labels: 
Selector: 
Type: 

IP: 

Port: 


Endpoints: 


Session Affinity: 


No events. 





Redis-master 

default 
name=Redis-master 
name=Redis-master 
ClusterIP 

169.169.208.57 

<unnamed> 6379/TCP 
172.17.0.58:6379 


None 


如 果 查 看 的 对 象 属于 某 个 特定 的 namespace， 则 需要 加 上 -- 
namespace=<namespace> 进 行 查 询 。 例 如 : 


A 


$ kubectl get service kube-dns --namespace=kube-system 





532 A aada 


在 需要 排 碍 容器 内 部 应 用 程序 生成 的 日 志 时 ， 我 们 可 以 使 用 kubectl 


logs<pod_name> 命 令 : 
$ kubectl logs redis-master-bobrO 
[1] 21 Aug 06:45:37.781 * Redis 2.8.19 (Q90000000/0) 64 b. 
[1] 21 Aug 06:45:37.781 # Server started, Redis version : 
[1] 21 Aug 06:45:37.781 # WARNING overcommit_memory is si 
[1] 21 Aug 06:45:37.782 # WARNING you have Transparent H 
[1] 21 Aug 06:45:37.782 # WARNING: The TCP backlog settil 





如 果 在 一 个 Pod 中 包含 多 个 容器 ， 则 需要 通过 -c 参 数 指定 容器 的 名 
称 来 进行 得 看 ， 例 如 : 


kubectl logs <pod_name> -c <container_name> 


这 个 命令 与 在 Pod 的 宿主 机 上 运行 docker logs<container_id> 的 效果 
是 一 样 的 。 


容器 中 应 用 程序 生成 的 日 志 与 容器 的 生命 周期 是 一 致 的 ， 所 以 在 容 
器 被 销毁 之 后 ， 容 器 内 部 的 文件 也 会 被 丢弃， 包括 日 志 等 。 如 果 需 要 保 
留 容 器 内 应 用 程序 生成 的 日 志 ， 则 一 方面 可 以 使 用 挂 载 的 Volume〈 存 
储 卷 ) 将 容器 产生 的 日 志保 存 到 宿主 机 ， 男 一 方面 也 可 以 通过 一 些 工具 
对 日 志 进 行 采集 ， 包 括 Fluentd、ElasticSearch 等 开源 软件 。 








5.3.3 #4Kuberneteshk 3 H 


如 果 在 Linux 系 统 上 进行 安装 ， 并 且 使 用 systemd 系 统 来 管理 


Kubernetes 服 务 ， 那 么 


systemd 的 journal 系统 会 接管 服务 程序 的 输出 日 


志 。 在 这 种 环境 中 ， 可 以 通过 使 用 systemd status 或 journalctl 工 具 来 查看 


系统 服务 的 日 志 。 


例如 ， 使 用 systemctl ”status 命 令 查 看 kube-controller-manager 服 务 的 


日 志 : 


# systemctl status kube-controller-manager -1 


kube-controller-manager.service - Kubernetes Controller | 


Loaded: 
Active: 
Docs: 
Main PID: 


CGroup: 


loaded (/usr/lib/systemd/system/kube-controlli 
active (running) since Fri 2015-08-21 18:36:2:! 
https://github.com/GoogleCloudPlatform/kubern 
20339 (kube-controller ) 


/system.slice/kube-controller-manager.service 


L-20339 /usr/bin/kube-controller-manager --logtostderr=fi 


Aug 21 18:36:29 kubernetes-master systemd[1]: Starting K 


Aug 21 18:36:29 kubernetes-master systemd[1]: Started Ku 


使 用 journalctl 命 令 查 看 : 


# journalctl -u kube-controller-manager 


-- Logs begin at Mon 2015-08-17 16:43:22 CST, end at Fri 
Aug 17 16:44:14 kubernetes-master systemd[1]: Starting K 


Aug 17 16:44:14 kubernetes-master systemd[1]: Started Ku 


如 果 不 使 用 systemd 系 统 接管 Kubernetes 服 务 的 标准 输出 ， 则 也 可 以 
通过 日 志 相 关 的 启动 参数 来 指定 日 志 的 存放 目录 。 








e --logtostderr=false: 不 输出 到 stderr。 

e --log-dir=/var/log/kubernetes: 日 志 的 存放 目录 。 

e --alsologtostderr=false: 设置 为 true 则 表示 将 日 志 输 出 到 文件 时 也 输 
出 到 stderr。 

e --v=0: glog 日 志 级 别 。 

e --vmodule=gfs*=2, test*=4: glog 基 于 模块 的 详细 日 志 级 别 。 





在 --log_dir 设 置 的 目录 中 可 以 查看 各 服务 进程 生成 的 日 志文 件 ， 日 
志文 件 的 数量 和 大 小 依赖 于 日 志 级 别 的 设置 。 例 如 kube-controller- 
manager 可 能 生成 的 几 个 日 志文 件 如 下 。 


e kube-controller-manager.ERROR。 

e kube-controller-manager.INFO. 

e kube-controller-manager.WARNING. 

e kube-controller-manager.kubernetes- 
master.unknownuser.log-ERROR.20150930-173939.9847 . 

e kube-controller-manager.kubernetes- 
master.unknownuser.log.INFO.20150930-173939.9847 - 

e kube-controller-manager.kubernetes- 
master.unknownuser.log.WARNING.20150930-173939.9847. 


在 大 多 数 情况 下 ， 我 们 从 WARNING 和 ERROR 级 别 的 日 志 中 就 能 找 
到 问题 的 原因 ， 但 有 时 还 是 需要 排查 INFO 级 别 的 日 志 甚至 DEBUG 级 别 
的 详细 日 志 。 此 外 ，etcd 服 务 也 属于 Kubernetes 集 群 中 的 重要 组 成 部 
分 ， 所 以 它 的 日 志 也 不 能 忽略 。 





如 有 果 是 某 个 Kubernetes 对 象 存 在 问题 ， 则 我 们 可 以 用 这 个 对 象 的 名 
字 作 为 天 键 字 搜索 Kubernetes 的 日 志 来 发 现 和 解决 问题 。 在 大 多 数 情 况 
下 ， 我 们 平常 所 过 到 的 主要 是 与 Pod 对 象 相关 的 问题 ， 比 如 无 法 创建 
Pod、Pod 局 动 后 就 停止 或 者 Pod 副 本 无 法 增加 等 。 此 时 ， 我 们 可 以 移 确 
定 Pod 在 哪个 节点 上 ， 然 后 登录 这 个 节点 ， 从 kubelet 的 日 志 中 得 询 该 Pod 
的 完整 日 志 ， 然 后 进行 问题 排查 。 对 于 与 Pod 扩 容 相 关 或 者 与 RC 相 关 的 
问题 ， 则 很 可 能 在 kube-controller-manager 及 kube-scheduler 的 日 志 上 找 出 
问题 的 关键 点 。 











男 外 ，kube-proxy 经 常 被 我 们 忽视 ， 因 为 即使 它 意 外 地 被 停止 ，Pod 
的 状态 也 是 正常 的 ， 但 会 导致 菜 些 服务 访问 异常 的 情况 。 这 些 错误 通常 
与 每 个 节点 上 的 kube-proxy 服 务 有 着 密切 的 关系。 过 到 这 些 问 题 时 ， 首 
先 要 排查 kube-proxy 服 务 的 日 志 ， 同 时 排查 防火 墙 服务 ， 特 别 是 要 留意 
防火 墙 中 是 否 有 人 为 添加 的 可 疑 规 则 。 





5.3.4 第 见 问 题 


本 节 对 Kubernetes 系 统 中 的 一 些 和 常见 问题 及 解决 方法 进行 说 明 。 


1. 由 于 无 法 下 载 pause 镜 像 导 致 Pod 一 直 处 于 Pending 的 状态 


以 redis-master 为 例 ， 使 用 如 下 配置 文件 redis-master-controller.yaml 
创建 RC 和 Pod: 


apiVersion: v1 
kind: ReplicationController 
metadata: 
name: redis-master 
labels: 
name: redis-master 
spec: 
replicas: 1 
selector: 
name: redis-master 
template: 
metadata: 
labels: 
name: redis-master 


spec: 


containers: 

- name: master 
image: kubeguide/redis-master 
ports: 


- containerPort: 6379 


执行 kubectl create-f redis-master-controller.yaml AKI) - 


但 在 查看 Pod 时 ， 发 现 其 总 是 无 法 处 于 Running 状 态 。 通 过 kubectl 
get pods 命 令 可 以 看 到 : 


$ kubectl get pods 
NAME READY STATUS 


redis-master-6yy70 0/1 Image: kubeguide/redis-ma 


进一步 使 用 kubectl describe pod redis-master-6yy7o 命 令 查看 该 Pod 的 
详细 信息 : 


$ kubectl describe pod redis-master-6yy70 


Name: redis-master-6yy70 
Namespace: default 

Image(s): kubeguide/redis-master 
Node: 127.0.0.1/127.0.0.1 
Labels: name=redis-master 
Status: Pending 

Reason: 


Message: 


IP: 


Replication Controllers: redis-master (1/1 replici 
Containers: 
master: 
Image: kubeguide/redis-master 
State: Waiting 
Reason: Image: kubeguide/redis-master is 
Ready: False 
Restart Count: 0 
Conditions: 
Type Status 
Ready False 
Events: 
FirstSeen LastSeen Count Frol 
Thu, 24 Sep 2015 19:19:25 +0800 Thu, 24 Sep 2015 
Thu, 24 Sep 2015 19:19:25 +0800 Thu, 24 Sep 2015 





可 以 看 到 ， 该 Pod 的 状态 为 Pending， 从 Message 部 分 显示 的 信息 可 
以 看 出 其 原因 是 image pull failed for gcr.io/google_containers/pause- 
amd64: 3.0， 说 明 系 统 在 创建 Pod 时 无 法 从 gcr.io 下 载 pause 镜 像 ， 所 以 导 
致 创建 Pod 失 败 。 


解决 方法 如 下 。 


(1) 如 果 服 务 器 可 以 访问 Internet， 并 且 不 希望 使 用 HTTPS 的 安全 
机 制 来 访问 gcr.io， 则 可 以 在 Docker Daemon 的 启动 参数 中 加 上 -- 
insecure-registry gcr.io 来 表示 可 以 进行 匿名 下 载 。 


(2) 如 果 Kubernetes 集 群 环 境 在 内 网 环境 中 ， 无 法 访问 gcr.io 网 
站 ， 则 可 以 先 通过 一 台 能 够 访问 gcr.io 的 机 器 将 pause 镜 像 下 载 下 来 ， 导 
出 后 ， 再 导入 内 网 的 Docker 私 有 镜像 库 中 ， 并 在 kubelet 的 启动 参数 中 加 
上 --pod_infra_container_image， 配 置 为 : 


--pod_infra_container_image=<docker_registry_ip>:<port>/ 


之 后 重新 创建 redis-master 即 可 正确 启动 Pod 了 o 


注意 ， 除 了 pause 镜 像 ， 其 他 Docker 镜 像 也 可 能 存在 无 法 下 载 的 情 
况 ， 与 上 述 情况 类 似 ， 很 可 能 也 是 网 络 配 置 使 得 镜像 无 法 下 载 ， 解 决 方 
法 同上 。 


2.Pod 创 建成 功 ， 但 状态 始终 不 是 Ready， 且 RESTARTS 的 数量 持续 
增加 


在 创建 了 一 个 RC 之 后 ， 通 过 kubectl get pods 命 令 查 看 Pod， 发 现 如 


$ kubectl get pods 
NAME READY STATUS RESTARTS AGE 
zk-bg-ri3ru 0/1 Running 3 37s 
$ kubectl get pods 
NAME READY STATUS RESTARTS AGE 


zk-bg-ri3ru 0/1 Running 5 1m 


$ kubectl get pods 

NAME READY STATUS RESTARTS AGE 
zk-bg-ri3ru 0/1 ExitCode:0 6 1m 
$ kubectl get pods 

NAME READY STATUS RESTARTS AGE 


ZK-bg-ri3ru 0/1 Running 7 1m 


可 以 看 到 Pod 已 经 创建 成 功 了 ， 但 Pod 的 状态 一 会 儿 是 Running， 一 
会 儿 是 ExitCode: 0，READY 列 中 始终 无 法 变 成 1， 而 且 
RESTARTS 〈 重 启 的 数量 ) 的 数量 不 断 增 加 。 


和 常 造 成 这 种 现象 是 因为 容器 的 启动 命令 不 能 保持 前 台 运 行 。 
本 例 中 的 Docker 镜 像 的 启动 命令 为 : 


zkServer.sh start-background 





在 Kubernetes 根 据 RC 定 义 创建 Pod 后 启动 容器 ， 容 器 的 启动 命令 执 
行 完成 时 ， 即 认为 该 容器 的 运行 已 经 结束 ， 并 且 是 成 功 结束 
(ExitCode=0) 。 然 后 ， 根 据 Pod 的 默认 重启 策略 定义 
(RestartPolicy=Always) ，RC 将 启动 这 个 容器 。 





新 的 容器 执行 启动 命令 后 仍然 会 成 功 结束 ， 然 后 RC 会 再 次 重启 该 
容器 ， 进 入 一 个 无 限 循环 的 过 程 中 。 


解决 方法 为 将 Docker 镜 像 的 局 动 命令 设置 为 一 个 前 台 运 行 的 命令 ， 


例如 : 


zkServer.sh start-foreground 


5.3.5 “寻求 帮助 





如 果 通 过 系统 日 志和 容器 日 志 都 无 法 找到 出 现 问题 的 原因 ， 则 还 可 
以 退 踊 源码 进行 分 析 ， 或 者 通过 一 些 在 线 途 径 寻 求 帮助 。 


e Kubernetes 的 常见 问题 参见 
https://github.com/GoogleCloudPlatform/kubernetes/wiki/User-FAQ. 

e Debugging 的 常见 问题 参见 
https://github.com/GoogleCloudPlatform/kubernetes/wiki/Debugging- 
FAQ. 

e Service 的 常见 问题 参见 
https://github.com/GoogleCloudPlatform/kubernetes/wiki/Services- 
FAQ. 

e StackOverflow 网 站 关于 Kubernetes 的 主题 参见 
http:/stackoverflow.comy/questions/tagged/kubernetes 或 
http://stackoverflow.com/questions/tagged/google-container-engine. 

e IRC 频 道 (#google-containers) 参见 
https://botbot.me/freenode/google-containers/。 

e Kubernetes 邮 件 列表 Email 参见 google- 


containers@googlegroups.com. 


5.4 Kubernetes v1.3 开 发 中 的 新 功能 


本 节 对 Kubernetes v1.3 版 本 的 正在 开发 中 的 一 些 新 功能 进行 介绍 ， 
包括 Pet Set (用 于 管理 有 状态 的 容器 应 用 ) ~ init container (Pod 中 的 初 
始 化 容器 ) 、Cluster Federation (集群 联邦 管理 ) “EAR. 








5.4.1 PetSet (有 状态 的 容器 ) 





在 Kubernetes 集 群 中 ， 组 成 一 个 微服 务 的 后 端 Pod 一 般 来 说 都 是 无 状 
态 的 容器 应 用 。 例 如 通过 RC 来 进行 管理 ， 只 需要 维持 Pod 的 副本 数量 即 
可 ， 当 某 个 Pod 失 败 时 残 直 接 销毁 并 重新 创建 一 个 新 的 Pod， 提 供 能 够 水 
平 扩展 的 微服 务 。 我 们 可 以 称 这 类 应 用 为 “Cattle”( 农 场 动 物 ) ， 即 单 
个 实例 不 是 特别 重要 ， 可 随时 被 蔡 换 。 





但 对 于 有 状态 的 应 用 来 说 ， 即 以 集群 的 方式 部 署 的 大 型 应 用 软件 ， 
每 个 实例 都 需要 具备 唯一 的 标识 ， 并 且 各 个 实例 可 能 还 有 局 动 顺序 的 要 
求 。v1.3 版 本 新 增 了 一 种 名 为 PetSet 的 资源 对 象 ， 用 于 支持 有 状态 的 容 
器 应 用 。 我 们 可 以 称 这 类 应 用 为 “Pet” EHA) ， 即 每 个 实例 都 非常 重 
要 ， 其 身份 不 应 被 别 的 实例 丛 换 。 











Pet ”Set 能 够 确保 为 每 个 Pet 设 置 一 个 唯一 的 里 份 标识 ， 包 括 如 下 几 
种 。 


e 唯一 且 不 变 的 hostname， 并 保存 在 DNS 中 。 
。 唯一 的 顺序 编写 ， 用 于 确保 各 实例 的 启动 顺序 。 
。 为 每 个 容器 提供 永久 存储 ， 与 其 hostname 和 启动 顺序 绑 定 。 





Pet Set 能 够 用 于 许多 应 用 场景 ， 如 下 所 述 。 


。 数据 库 应 用 ， 例 如 MySQL 或 PostgreSQL， 其 每 个 实例 都 需要 挂 载 一 
个 外 部 的 永久 存储 。 
。 集群 化 的 应 用 软件 ， 例 如 ZooKeeper、etcd、ElasticSearch 等 需要 集 





群 中 的 各 成 员 有 稳定 的 号 份 。 
下 面 的 例子 描述 了 PetSet 的 创建 和 用 法 。 


petset.yaml 
# 使 用 headless Service， 以 创建 相应 Pod 的 DNS 记录 





apiVersion: v1 

kind: Service 

metadata: 
name: nginx 
labels: 


app: nginx 


spec: 
ports: 
- port: 80 
name: web 


# *.nginx.default.svc.cluster.local 
clusterIP: None 
selector: 

app: nginx 


# PetSet 的 定义 





apiVersion: apps/vialphat 
kind: PetSet 
metadata: 

name: web 


spec: 


serviceName: "nginx" 
replicas: 2 
template: 
metadata: 
labels: 
app: nginx 


annotations: 


pod.alpha.kubernetes.io/initialized: "true" 


spec: 
terminationGracePeriodSeconds: 0 
containers: 


- name: nginx 


image: gcr.io/google_containers/nginx-slim:0.8 


ports: 


- containerPort: 80 


name: web 
volumeMounts: 
- name: www 


mountPath: /usr/share/nginx/html 
volumeClaimTemplates: 
- metadata: 
name: www 


annotations: 


volume.alpha.kubernetes.io/storage-class: 


spec: 
accessModes: [ "ReadwriteOnce" | 


resources: 


anythi 


requests: 


storage: 1Gi 





在 PetSet 定 义 中 ， 需 要 设置 永久 存储 “volumeClaimTemplates”， 需 要 
系统 管理 员 预 先 创建 好 外 部 PV (Persistent Volume) ， 才 能 给 PetSet 使 
用 。 


使 用 kubectl create 命 令 创建 该 PetSet: 


$ kubectl create -f petset.yaml 
service "nginx" created 


petset "nginx" created 


查看 创建 好 的 Pod 的 信息 : 


$ kubectl get pods 


NAME READY STATUS RESTARTS AGE 
web -0 1/1 Running 0 10m 
web-1 1/1 Running 0 10m 


可 以 看 到 每 个 Pod 的 名 称 不 再 是 通过 RC 创建 的 带 有 一 个 UUID 的 名 
称 ， 而 是 由 “petset ”name” 与 一 个 序列 号 组 成 的 特定 名 称 : web-0 和 web- 
1。 


而 Pod 名 称 也 就 是 该 Pod 的 hostname， 即 PetSet 为 每 个 Pet 设 置 了 稳定 
的 主机 名 。 


# kubectl exec web-0 -- sh -c 'hostname' 


web -0 
# kubectl exec web-1 -- sh -c 'hostname' 


web-1 


同时 ， 每 个 Pod 的 网 络 身 份 也 通过 Service 的 定义 被 创建 出 来 。 根 据 
Service 的 定义 ， 该 Service 将 在 DNS 中 生成 一 条 没有 CjlusterIP 的 记录 : 


nginx.default.svc.cluster.local 


该 Service 的 后 端 为 两 个 Pet 的 地 址 〈 可 以 看 成 是 Pet 的 服务 名 ) : 


web-0.nginx.default.svc.cluster.local 


web-1.nginx.default.svc.cluster.local 


这 两 个 Pet 的 地 址 web-0.nginx 和 web-1.nginx 将 作为 每 个 Pet 的 稳定 网 
络 身 份 被 系统 保存 在 DNS 中 ， 供 客户 端 应 用 访问 。 


接 下 来 通过 一 个 busybox 容 器 执行 nslookup， 验 证 Pet 的 服务 地 址 ; 


# kubectl run -i --tty --image busybox dns-test --restar 


Hit enter for command prompt 


查询 web-0.nginx: 

/ # nslookup web-0.nginx 
server: 169.169.0.100 
Address 1: 169.169.0.100 


Name: web-0.nginx 


Address 1: 172.17.1.2 


查询 web-1.nginx: 

/ # nslookup web-1.nginx 
Server: 169.169.0.100 
Address 1: 169.169.0.100 


Name: web-1.nginx 


Address 1: 172.17.1.3 


如 果 直 接 查 询 Nginx 服 务 (headless service) ， 则 系统 将 返回 后 端 两 
个 Pet 的 也 地 址 列表 : 


/ # nslookup nginx 
server: 169.169.0.100 
Address 1: 169.169.0.100 


Name: nginx 
Address 1: 172.17.1.2 


Address 2: 172.17.1.3 





借助 于 headless _ service 的 功能 ， 可 以 实现 各 Pet 相互 之 间 进 行 发 现 和 
Wily 


当前 版 本 Pet Set 的 使 用 限制 如 下 。 





e 只 有 replicas 字 段 可 以 被 更 新 ， 但 更 新 后 Pet Set 仍 然 是 按 顺 序 依次 创 
建 各 Pet。 


。 删除 petset 时 ， 系 统 不 会 自动 删除 已 经 运行 中 的 Pets， 需 要 手工 删 
除 。 


。 出 于 数据 安全 的 考虑 ， 在 删除 Pet 时 系统 不 会 自动 删除 该 Pet 使 用 的 
PV 存储 。 


© 目前 不 文 持 Pet 镜 像 的 深 动 升级 操作 ， 需 要 手工 完成 。 


5.4.2 Init Container (初始 化 容器 》) 





在 很 多 应 用 场景 中 ， 应 用 在 启动 之 前 都 需要 一 些 初 始 化 的 操作 ， 例 
如 : 


等 等 其 他 关联 组 件 正确 运行 (例如 数据 库 或 菜 个 后 台 服 务 〉; 

基于 环境 变量 或 配置 模板 生成 配置 文件 ; 

从 远程 数据 库 获 取 本 地 所 需 配置 ， 或 者 将 目 身 注册 到 茶 个 中 央 数 据 
PE; 

下 载 相关 依赖 包 ， 或 者 对 系统 进行 一 些 预 配 置 操 作 。 


Kubernetes Vv1.3 版 本 引入 了 一 个 Alpha 版 本 的 新 特性 : init 
container， 用 于 在 启动 普通 容器 之 前 局 动 一 个 或 多 个 “初始 化 ?容器 ， 完 

普通 容器 所 需要 的 预 置 条 件 ， 如 图 5.22 所 示 。init container 与 普通 容 骼 
本 质 上 是 一 样 的 ， 但 它们 是 仅 运 行 一 次 就 结束 的 任务 ， 并 且 必 须 成 功 执 
行 完 成 后 ， 系 统 才能 继续 执行 下 一 个 容器 。 根 据 Pod 的 重 司 策略 
(RestartPolicy) ， 当 init container 执 行 失败 ， 在 设置 了 
RestartPolicy=Never 时 ，Pod 将 会 启动 失败 ; 而 设置 RestartPolicy=Always 
时 ，Pod 将 会 被 系统 自动 重启 。 


Pod 
init 容器 1 
J 


init A at 2 
l 


Application 容器 


图 5.22 init container 


在 当前 的 版 本 中 要 启用 init container 的 配置 ， 需 要 在 Pod 的 annotation 
字段 中 设置 pod.alpha.kubernetes.io/init-containers 来 定义 需要 执行 的 初始 
化 容器 列表 。 


下 面 ， 以 Nginx 应 用 为 例 ， 在 启动 Nginx 之 前 ， 通 过 初始 化 容器 
busybox 为 Nginx 创 建 一 个 index.html 主 页 文件 。 


nginx-init-containers.yaml 
apiversion: vi 
kind: Pod 
metadata: 
name: nginx 


annotations: 


pod.alpha.kubernetes.io/init-containers: '[ 


{ 
"name": "install", 
"image": "busybox", 
"command": ["wget", "-0", "/work-dir/index.h 
"volumeMounts": [ 
{ 
"name": "workdir", 
"mountPath": "/work-dir" 
} 
] 
} 
]， 
spec: 
containers: 


- name: nginx 

image: nginx 

ports: 

- containerPort: 80 

volumeMounts: 

- name: workdir 

mountPath: /usr/share/nginx/html 

dnsPolicy: Default 
volumes: 
- name: workdir 


emptyDir: {} 


创建 这 个 Pod: 


# kubectl create -f nginx-init-containers.yaml 


pod "nginx" created 


在 运行 init ”container 的 过 程 中 ， 查 看 Pod 的 状态 ， 可 见 Init 过 程 还 未 
完成 : 


# kubectl get pods 
NAME READY STATUS RESTARTS AGE 


nginx 0/1 Init:0/1 0 1m 


“init container 成 功 执行 完成 ， 系 统 继续 局 动 Nginx 容 器 ， 再 次 查看 
Pod 的 状态 : 


# kubectl get pods 
NAME READY STATUS RESTARTS AGE 


nginx 1/1 Running 0 7S 


EA PoF, H UE RAII ISAT Pod FN TA ait 


# kubectl describe pod nginx 


Name: nginx 
Namespace: default 
ee (H) 

Events: 


FirstSeen LastSeen Count From 


As 
As 
As 
As 
3s 
3s 


2S 


As 
As 
As 
As 
3s 
3s 


2S 


BBP BE EBE B B B 


{default- 


{kubelet 
{kubelet 
{kubelet 
{kubelet 
{kubelet 
{kubelet 


scheduli 
k8s-nodi 
k8s-nod 
k8s-nodi 
k8s-nod 
k8s-nod 


k8s-nod 


在 init container 的 后 续 演进 中 ， 将 进一步 考虑 Pod 的 资源 使 用 限制 、 
健康 检查 、 镜 像 更 新 等 问题 。 


5.4.3 ClusterFederation 〈 集 群 联邦 ) 


集群 联邦 是 管理 多 个 Kubernetes 集 群 的 集群 ， 用 于 多 个 集群 中 的 服 
务 统一 管理 ， 以 及 当 一 个 集群 发 生 故障 时 ， 能 够 将 业务 恢复 到 其 他 集群 
上 ， 如 图 5.23 所 示 。 目 前 集群 联邦 只 能 在 谷歌 或 亚马逊 的 公有 云 上 进行 
配置 和 使 用 。 





图 5.23 ”集群 联邦 


集群 联邦 的 主要 组 件 由 Federation Control Plane 〈 控 制 平 面 ) 来 完成 
对 多 个 集群 的 管控 ， 其 核心 组 件 包 括 federation-apiserver 和 federation- 
controller-manager 和 etcd， 可 以 在 已 经 存在 的 一 个 Kubernetes 集 群 上 以 
Pod 的 形式 启动 这 些 Federation 组 件 。 


下 面 以 在 GCE 上 运行 一 个 ClusterFederation 为 例 ， 创 建 federation- 


apiserver 和 federation-controller-manager 的 命令 为 : 


$ KUBERNETES_PROVIDER=gce FEDERATION_DNS_PROVIDER=google 


各 个 参数 的 含义 如 下 。 


。 KUBERNETES_PROVIDER: 云 服 务 商 。 

e FEDERATION_DNS_PROVIDER: 可 以 是 google-clouddns 或 者 aws- 
route53。 如 果 已 经 把 KUBERNETES_PROVIDER 设 置 为 gce、gke 及 
aws 中 的 一 个 ， 那 么 系统 会 自动 设置 这 一 变量 。 该 设置 项 用 于 为 联 
邦 服务 提供 域名 解析 能 力 。 当 联邦 中 的 Kubernetes 集 群 上 的 Pod 或 者 
Service 发 生变 更 的 时 候 ， 会 在 DNS 记录 上 做 出 相应 的 变更 。 

e FEDERATION_NAME: 联邦 的 名 称 ， 这 一 名 称 也 会 反映 在 DNS 记 
录 之 中 。 

e DNS_ZONE_NAME: DNS 记录 的 域名 。 用 户 需 要 购买 和 使 用 这 个 
域名 ， 让 FEDERATION_DNS_PROVIDER 能 够 为 这 一 域名 的 查询 
提供 正确 的 解析 结果 。 





通过 上 面 的 命令 会 创建 一 个 federation 命 名 空间 ， 并 创建 两 个 


Deployment 对 象 : federation-apiserver 及 federation-controller-manager。 
验证 创建 出 来 的 deployment: 


$ kubectl get deployments --namespace=federation 


NAME DESIRED CURRENT | 
federation-apiserver 1 1 
federation-controller-manager 1 1 1 


federation-up.sh 还 会 在 kubeconfig 中 创建 一 个 新 纪录 ， 用 来 和 联邦 
APIServer 进 行 通信 。 可 以 使 用 kubectlconfigview 来 查看 。 


另外 ，federation-up.sh 创 建 的 federation-apiserver Pod 中 包含 的 etcd 容 
器 使 用 了 PV 持 久 卷 ， 用 来 提供 持久 化 数据 存储 ， 目 前 只 能 在 AWS、 
GKE 或 GCE 坏 境 中 进行 创建 。 具 体 的 PV 设置 可 以 通过 修改 


federation/manifests/federation-apiserver-deployment.yaml 来 完成 。 


在 联邦 控制 平面 局 动 之 后 ， 就 可 以 对 现 有 的 Kubernetes 集 群 进 行 纳 
Sx 


mi 


首先 ， 我 们 需要 创建 一 个 secret 对 象 ， 其 中 包含 了 Kubernetes 集 群 的 
kubeconfig， 联 邦 将 会 用 这 一 内 容 和 受 管 集群 进行 通信 。 假 设 kubeconfig 
文件 位 于 /clusterl/kubeconfig， 用 下 面 的 命令 来 创建 secret: 


$ kubectl create secret generic cluster1 --namespace=fed 


文件 名 kubeconfig 将 用 于 设置 secrete 的 key 名 称 。 


创建 好 secret 之 后 ， 就 可 以 注册 集群 了 ， 一 个 集群 对 象 的 yaml 配 置 
文件 如 下 : 


apiVersion: federation/vibetal 
kind: Cluster 
metadata: 
name: cluster1 
spec: 
serverAddressByClientCIDRs: 
- ClientCIDR: <client-cidr> 
serverAddress: <apiserver -address> 


secretRef: 


name: <Secret-name> 


需要 把 <client-cidr>、<apiserver-address> 及 <secret-name> 蔡 换 为 实 
际 内 容 。<secret-name> 是 前 面 刚刚 创建 的 secret 的 名 称 。 
serverAddressByClientCIDRs 包 含 一 系列 地 址 ， 符 合 CIDR 的 客户 问 才 能 
连接 服务 器 的 这 一 地 址 。 我 们 可 以 设置 服务 器 地 址 的 CIDR 
为 “0.0.0.0/0”， 这 样 所 有 的 客户 端 都 可 以 访问 。 另 外 ， 如 果 硕 望 内 部 客 
户 端 使 用 服务 器 的 clusterIP， 则 可 以 把 这 一 卫 设 置 为 serverAddress， 然 后 
设置 clientCIDR 为 集群 内 的 Pod 地 址 范围 。 


将 该 yaml 文 件 保存 为 /clusterl/cluster.yaml， 运 行 下 面 的 命令 来 进行 
集群 的 纳 管 : 


$ kubectl create -f /clusteri/cluster.yaml --context=fed 





设置 --context=federation-cluster 意 思 是 将 请 求 发 往 联 邦 的 federation- 


apiserver. 





查看 纳 管 的 结果 : 





$ kubectl get clusters --context=federation-cluster 
NAME STATUS VERSION AGE 


cluster1 Ready 3m 


当 集 群 纳 管 之 后 ， 束 可 以 使 用 集群 联邦 的 功能 


为 了 支持 跨 集群 的 服务 发 现 机 制 ， 需 要 扩展 KubeDNS 服 务 ， 通 过 -- 
federations 参 数 设 置 集群 联邦 的 总 DNS 服 务 : 


--federations=${FEDERATION_NAME}=${DNS_DOMAIN_NAME} 


可 以 通过 编辑 现 有 KubeDNS 的 RC 中 所 包含 的 Pod 模 板 来 为 Pod 加 入 
这 一 参数 ， 删 除 当前 运行 的 Pod 之 后 ，RC 就 会 根据 新 的 模板 创建 带 有 联 
邦 DNS 信 息 的 KubeDNS 服 务 了 。 
$ kubectl get rc --namespace=kube-system 


kube-dns 的 RC 名 是 kube-dns-[id] 的 形式 ， 用 edit 进 行 编辑 : 


$ kubectl edit rc <rc-name> --namespace=kube-system 


在 弹出 的 yaml 文 件 中 加 入 --federation 参 数 ， 保 存 退 出 ， 然 后 查询 并 
删除 现 有 的 Pod。 


$ kubectl delete pods <pod-name> --namespace=kube-system 
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$ kubectl get clusters --context=federation-cluster 


NAME STATUS VERSION AGE 
cluster1 Ready 3m 
cluster2 Ready 3m 
cluster3 Ready 3m 


cluster4 Ready 3m 


在 这 4 个 集群 上 创建 Nginx 服 务 : 


$ kubectl --context=federation-cluster create -f service 





等 待 该 服务 在 所 有 集群 上 创建 完成 ， 并 且 集群 联邦 内 的 服务 也 更 新 
se, EU 


I 


查看 服务 的 状态 ， 可 以 看 到 在 每 个 集群 上 创建 的 Loadbalancer 的 IP 
地 址 : 


$ kubectl --context=federation-cluster describe services 


Name: nginx 
Namespace: default 
Labels: run=nginx 
Selector: run=nginx 
Type: LoadBalancer 
IP: 


LoadBalancer Ingress: 104.197.246.190, 130.211.57.243, 


Port: http 80/TCP 
Endpoints: <none> 

Session Affinity: None 

No events. 


登录 其 中 一 个 集群 ， 查 看 由 federation-controller-manager 创 建 的 
Nginx 服 务 : 


$ kubectl --context=cluster1 get svc nginx 


NAME CLUSTER-IP EXTERNAL - IP PORT(S) AGE 


nginx 10.63.250.98 104.199.136.89 80/TCP 9m 


可 以 看 到 集群 联邦 通过 在 每 个 集群 上 创建 一 个 同名 的 服务 ， 但 此 时 
由 于 每 个 集群 的 Service 后 端 还 没有 运行 任何 Pod， 所 以 这 些 联邦 服务 还 
无 法 正常 工作 。 


接 下 来 通过 在 每 个 集群 上 运行 Pod 来 支撑 Service: 


$ kubectl --context=cluster1 run nginx --image=nginx:1.1 
$ kubectl --context=cluster2 run nginx --image=nginx:1.1 
$ kubectl --context=cluster3 run nginx --image=nginx:1.1 


$ kubectl --context=cluster4 run nginx --image=nginx:1.1 


当 这 些 Pod 成 功 运行 后 ，Service 将 被 集群 联邦 设置 为 正常 状态 ， 然 
后 集群 联邦 将 会 配置 相应 的 公共 DNS 记录 。 假 设 使 用 的 是 Google Cloud 
DNS， 并 且 DNS 域 名 为 example.com， 则 可 以 看 到 每 个 集群 上 的 Nginx 服 
务 都 被 设置 好 了 一 个 DNS 名 ， 可 供 其 他 应 用 访问 时 使 用 : 


$ gcloud dns managed-zones describe example-dot-com 
creationTime: '2016-06-26T18:18:39.229Z' 

description: Example domain for Kubernetes Cluster Feder 
dnsName: example.com. 

id: '3229332181334243121' 

kind: dns#managedZone 

name: example-dot-com 

nameServers: 


- ns-cloud-ai1.googledomains.com. 


- ns-cloud-a2.googledomains.com. 
- ns-cloud-a3.googledomains.com. 


- ns-cloud-a4.googledomains.com. 


$ gcloud dns record-sets list --zone example-dot-com 
NAME 

example.com. 

example.com. 
nginx.mynamespace.myfederation.svc.example.com. 
nginx.mynamespace.myfederation.svc.cluster1.example.com. 
nginx.mynamespace.myfederation.svc.cluster2.example.com. 
nginx.mynamespace.myfederation.svc.cluster3.example.com. 
nginx.mynamespace.myfederation.svc.cluster4.example.com. 


nginx.mynamespace.myfederation.svc.cluster4.example.com. 
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6.1 Kubernetes 源 码 结构 和 编 详 步 又 


Kubernetes 的 源码 现在 托管 在 GitHub 上， 地 址 为 
https://github.com/googlecloudplatform/kubernetes。 


编译 脚本 存放 在 build 子 目录 下 ， 在 Linux 环 境 ( 可 以 是 虚拟 机 〉 中 
执行 如 下 命令 即 可 完成 代码 的 编译 过 程 : 


git clone https://github.com/GoogleCloudPlatform/kuberne 
cd kubernetes/build 


./release.sh 


制作 release 的 过 程 其 实 有 不 少 有 意思 的 事情 发 生 ， 包 括 局 动 Docker 
容 吉 来 安装 Go 语言 环境 、etcd 等 ， 读 者 各 有 兴趣 则 可 以 查看 release.sh 脚 
本 。 另 外 ， 如 果 编 译 环境 是 通过 HTTP 代 理 上 网 的 ， 则 需要 设置 好 Git 与 
Docker 相 关 的 HITP 代 理 参数 ， 同 时 在 文件 kubernetes/build/build- 
image/Dockerfile 中 增加 如 下 HTTP 代 理 参 数 。 





e ENV http_proxy=http://username: password@proxyaddr: 
proxyport. 


e ENV https_proxy=http://username: password@proxyaddr: 
proxyport. 


在 编译 过 程 中 产生 的 与 Docker 相 关 的 docker image, dockerfile X% r 
译 好 的 二 进 制 文件 包 ， 则 存放 在 kubernetes/_output 目 录 下 ， 这 个 目录 总 
共有 4 个 子 目录 : dockerized、images、release-stage、release-tars， 我 们 
关心 后 两 个 目录 ， 其 中 release-stage 目 录 下 存放 的 是 文 持 linux-amd64 架 
构 的 Server 端 的 二 进 制 可 执行 文件 〈 放 在 server 子 目录 下 ) ， 以 及 文 持 不 
同 平台 的 Client 端 的 二 进 制 可 执行 文件 ( 放 在 client 子 目录 下 ) ，release- 
tars 则 存放 的 是 release-stage 目 录 下 各 级 子 目 录 的 压缩 包 ， 与 从 官方 网 站 
下 载 的 完全 一 样 。 








考虑 到 学 习 和 调试 Kubernetes 代 码 的 便利 性 ， 我 们 接 下 来 介绍 如 何 
在 Windows 的 LiteIDE 开 发 环境 中 完成 Kubernetes 代 码 的 编译 和 调试 。 本 
文 假设 Windows 上 的 GO 运行 时 框 杂 和 LiteIDE 开 发 环境 已 经 建立 好 ， 并 
通过 git clone 命 令 已 经 将 
https://github.com/GoogleCloudPlatform/kubernetes.git 下 载 到 本 地 C: 
\kubernetes 目 录 中 。 通 过 分 析 Kubernetes 的 目录 结构 ， 我 们 发 现 
Kubernetes 的 源码 都 在 pkg 子 目录 下 。 接 下 来 建立 k8s 工 程 目录 ， 目 录 位 
HNC: \project\go\k8s， 并 在 里 面 建立 src、pkg 两 个 子 目 录 ， 然 后 把 C: 
\kubernetes\Godeps\_ workspace\src 全 部 转移 到 C: \project\go\k8s\src 目 录 
下 ， 因 为 这 里 是 Kubernetes 源 人 码 的 所 有 依赖 包 ， 所 以 如 有 果 手 动 一 个 一 个 
地 下 载 ， 则 恐怕 以 国内 的 网 速 一 天 也 搞 不 定 。 转 移 完 成 后 ，C: 
\project\go\k8s\src 的 目录 结构 包括 如 下 内 容 : 




















C:\project\go\k8s\src>dir 
2015-07-14 11:56 <DIR> bitbucket.org 


2015-07-14 11:56 <DIR> code.google.com 


2015-07-17 12:30 <DIR> github.com 
2015-07-14 11:56 <DIR> golang.org 
2015-07-14 11:56 <DIR> google.golang.org 
2015-07-14 11:56 <DIR> gopkg.in 
2015-07-14 11:56 <DIR> speter.net 


接 下 来 把 C: \kubernetes 的 整个 目录 移动 到 C: 
\project\go\k8s\src\github.com\GoogleCloudPlatform\ F, [Al7yKubernetes 
的 源码 包 的 完整 名 字 
为 “github.com/GoogleCloudPlatform/kubernetes/pkg”。 上 述 工 作 完 成 以 
后 ， 所 有 的 源码 都 在 C: \project\go\k8s\src 目 录 下 了 ， 我 们 用 LiteIDE 打 
JFC: \project\go\k8s， 单 击 菜 单 “ 查 看 ” “管理 Gopath” 添 加 目录 “C: 
\project\go\k8s”， 然 后 可 以 进入 目录 
github.com/GoogleCloudPlatform/kubernetes/pkg 下 ， 逐 一 编译 每 个 
package 目 录 了 ， 如 图 6.1 所 示 。 
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图 6.1 ”LiteIDE 编 译 Kubernetes 的 package 


在 每 个 package 都 编译 完成 以 后 ， 我 们 可 以 尝试 启动 kube-scheduler 
进程 : 在 LiteIDE 里 打开 
github.com/GoogleCloudPlatform/kubernetes/pkg/plugin/cmd/kube- 
scheduler/scheduler.go， 并 且 按 快捷 键 Ctrlt+R， 你 会 惊奇 地 发 现 这 个 
Kubernetes 服 务 右 问 进 程 竟然 也 能 在 Windows 下 运行 起 来 。 以 下 是 
LiteIDE 输 出 的 控制 台 日 志 : 


c:/go/bin/go.exe build -i [C:/project/go/k8s/src/github.' 
成 功 : 进程 退出 代码 9。 
C:/project/go/k8s/src/github.com/GoogleCloudPlatform/kub 
WO717 16:05:26.742413 11344 server.go:83] Neither --kube 
E0717 16:05:27.747413 11344 reflector.go:136] Failed to 
E0717 16:05:27.748413 11344 reflector.go:136] Failed to 





在 Kubernetes 的 源码 里 包括 不 少 单元 测试 ， 你 可 以 在 LiteIDE 里 运行 
通过 ， 但 有 部 分 测试 代码 目前 在 windows 上 无 法 通过 ， 毕 竟 Kubernetes 
是 为 Linux 打 造 的 。 接 下 来 我 们 分 析 下 Kubernetes 源 码 的 整体 结构 ， 
Kubernetes 的 源码 总 体 分 为 pkg、cmd、plugin、test 等 顶级 package， 其 中 
pkg 为 Kubernetes 的 主体 代码 ，cmd 为 Kubernetes 所 有 后 台 进 程 的 代码 

(如 kube-apiserver 进 程 、kube-controller-manager 进 程 、kube-proxy 进 
程 、kubelet 进 程 等 ) ，plugin 则 包括 一 些 插 件 及 kuber-scheduler 的 代码 ， 
test 包 是 Kubermetes 的 一 些 测试 代码 。 





A 


从 总 体 来 看 ，Kubernetes 1.0 的 当前 包 绪 构 还 是 有 点 乱 ， 开 源 团 队 还 
在 继续 优化 中 ， 可 以 从 源码 的 TODO 注 释 中 看 出 这 一 点 。 表 6.1 给 出 了 
Kubernetes 当 前 主要 package 的 源码 分 析 结 果 。 


表 6.1 Kubernetes 主 要 package 的 源码 分 析 结 


package 模 块 用 途 
admission 权限 控制 框架 ， 采 用 了 责任 链 模 式 、 插 件 机 制 
api Kubernetes 所 提供 的 Rest API 接口 的 相关 类 ， 例 如 接口 数据 结构 相关 的 MetaData 结构 、 
Volume 结构 、Pod 结构 、Service 结构 等 ， 以 及 数据 格式 验证 转换 工具 类 等 ， 由 于 API 是 分 








版 本 的 ， 所 以 这 里 是 每 个 版 本 一 个 子 Package， 例 如 vibeta, v1 及 latest 

apiserver 实现 了 HTTP Rest 服务 的 一 个 基础 性 框架 ， 用 于 Kubernetes 的 各 种 Rest API 的 实现 ， 在 
apiserver 包 里 也 实现 了 HTTP Proxy， 用 于 转发 请 求 ( 到 其 他 组 件 ， 比 如 Minion 节点 上 ) 
auth 3A 认证 模块 ， 包 括 用 户 认 证 、 鉴 权 的 相关 组 件 




















续 表 
是 Kubernetes 中 公用 的 客户 端 部 分 的 相关 代码 ， 实 现 协议 为 ETTPRest， 用 于 提供 一 个 具 
(EERE. GMAT Pod, Service 等 的 增删 改 查 ， 这 个 模块 也 定义 了 kubeletClient， 同 时 为 
了 高 效 地 进行 对 象 查询 ， 冰 模块 也 实现 了 一 个 带 缓存 功能 的 存储 接口 Store 

定义 了 云 服 提 供 商 运行 Kubernetes 所 需 的 接口 , 包括 TCPLoadBalancer 的 获取 和 创建 : 获 
取 当 前 环境 中 的 节点 列表 《节点 是 一 个 云 主机 ) 和 节点 的 具体 信息 ;获取 Zone 信息 ; 获 
取 和 管理 路 由 的 接口 等 , 默认 实现 了 AWS, GCE. Mesos. OpenStack. RackSpace 等 云 服 
务 供应 商 的 接口 

这 部 分 提供 了 资源 控制 器 的 简单 框架 ， 用 于 处 理 资源 的 添加 、 变 更 、 晋 除 等 事件 的 派发 和 
执行 ， 同 时 实现 了 Kubernetes 的 ReplicationController $) Rp E$ 


Kubernetes 的 命令 行 工具 kubectl 的 代码 模块 ， 包 括 创建 Pod、 服 务 、Pod 扩容 、Pod Ra) 
升级 等 各 种 命令 的 具体 实现 代码 


Kubernetes 的 kubelet 的 代码 模块 ， 是 Kubernetes 的 核心 模块 之 一 ， 定 义 了 Pod 容器 的 接 

口 ， 提 供 了 Docker 与 Rit 两 种 容器 实现 类 ， 完 成 了 容器 及 Pod 的 创建 ， 以 及 容器 状态 的 

监控 、 销 毁 、 垃 圾 回收 等 功能 

Kubemetes 的 Master 节点 代码 模块 ， 创 建 NodeRegistry、PodRegistry、ServiceRegistry、 | / 
EndpointRegistry 等 组 件 ， 并 且 启 动 Kubemetes 自身 的 相关 服务 ， 服 务 的 ClusterIp 地 址 分 

配 及 服务 的 NodePort 端口 分 配 ， 也 是 在 这 里 完成 的 

Kubernetes 的 服务 代理 和 负载 均衡 相关 功能 的 模块 代码 , 目前 实现 了 round-robin 的 负载 均 
mk 

Kubernetes 的 NodeRegistry. PodeRegistry. ReplicationControllerRegistry. ServiceRegistry. 
EndpointRegistry. Persistent VolumeRegisty 等 注册 表 服 务 的 接口 及 对 应 Rest 服务 的 相关 代 

码 

为 了 让 多 个 API 版 本 共存 ， 需 要 采用 一 些 设计 来 完成 不 同 API 版 本 的 数据 结构 的 转换 ，API 
中 数据 对 象 的 Encode Decode 逻辑 也 最 好 集中 化 ，Runtime 包 就 是 为 了 这 个 目的 而 设计 的 

实现 了 Kubemetes 的 各 种 Volume 类 型 ， 分 别 对 应 亚马逊 ESB 存储、 谷歌 GCE 的 存储 、 

Linux Host 目录 存 鳍 、GlusterFS 存储 、iSCSI 存 信 、NES 存储 、RBD 存储 等 ，volume 包 | 
同时 实现 了 Kubernetes 容器 的 Volume 4/2242. MRH 

包括 了 Kubernetes 所 有 后 台 进 程 的 代码 (如 kube-apiserver 进程 、kube-controller-manager 

进程 、kube-proxy 进程 、kubelet 进程 等 )， 而 这 些 进程 具体 的 业务 运 辑 代码 则 都 在 pks 中 


中 
少 
> 
少 
少 
实现 了 
中 


如 HTTP BasicAuth. X509 证 书 认 证 :pkg/scheduler 子 包 则 定义 了 一 些 具 体 的 Pod 调度 器 


子 包 emd/kuber-scheduler 实现 了 Schedule Server 的 框架 ， 用 于 执行 具体 的 Scheduler 的 调 
度 ,pkg/admission 子 包 则 实现 了 Admission 权限 框架 的 一 些 默 认 实 现 类 ,例如 ahwaysAdmit、 
alwaysDeny 等 ; pks/auth 子 包 实 现 了 权限 认证 框架 (auth 包 的 ) 里 定义 的 认证 接口 类 ， 例 
(Scheduler) 


6.2 ”kube-apiserver 进 程 源 码 分 析 


Kubernetes APIServer 是 由 kube-apiserver 进 程 实现 的 ， 它 运行 在 
Kubernetes 的 管理 节点 Master 上 并 对 外 提供 Kubernetes Restful API 服 
务 ， 它 提供 的 主要 是 与 集群 管理 相关 的 API 服 务 ， 例 如 校 验 pod、 
service. replication controller 的 配置 并 存储 到 后 问 的 etcd Server 上 。 下 面 
我 们 分 别 对 其 启动 过 程 、 关 键 代 码 分 析 及 设计 总 结 等 进行 深入 讲解 。 





6.2.1 ”进程 启动 过 程 


kube-apiserver 进 程 的 入 口 类 源码 位 置 如 下 : 


github/com/GoogleCloudPlatform/kubernetes/cmd/kube-apise 


入 口 main ©) 函数 的 逻辑 如 下 : 


func main() { 
runtime .GOMAXPROCS( runtime .NumCPU( ) ) 


rand.Seed(time.Now().UTC().UnixNano() ) 


s := app.NewAPIServer () 


s.AddFlags(pflag.CommandLine ) 


util.InitFlags() 
util.InitLogs() 
defer util.FlushLogs() 


verflag.PrintAndExitIfRequested() 
if err := s.Run(pflag.CommandLine.Args()); err != ni. 


fmt.Fprintf(os.Stderr, "%v\n", err) 


os.Exit(1) 





上 述 代码 的 核心 为 下 面 三 行 ， 创 建 一 个 APIServer 结 构 体 并 将 命令 
行 启动 参数 传 入 ， 最 后 启动 监听 : 


s := app.NewAPIServer() 
s.AddFlags(pflag.CommandLine) 


s.Run(pflag.CommandLine.Args() ) 





我 们 先 来 看 看 都 有 哪些 常用 的 命令 行 参数 被 传递 给 了 APIServer 对 
象 ， 下 面 是 运行 在 Master 节 点 的 kube-apiserver 进 程 的 命令 行 信息 








/usr/bin/kube-apiserver --logtostderr=true --etcd_server 


可 以 看 到 关键 的 几 个 参数 有 etcd_servers 的 地 址 、APIServer 绑 定 和 
监听 的 本 地 地 址 、kubelet 的 运行 端口 及 Kubernetes 服 务 的 clusterIP 地 址 。 


下 面 是 app.NewAPIServer ©) 的 代码 ， 我 们 看 到 这 里 的 控制 还 是 很 
全 面 的 ， 包 括 安全 控制 〈CertDirectory、HTTPS 默 认 启 动 ) 、 权 限 控制 
(AuthorizationMode, AdmissionControl) 、 服 务 限 流 控制 (APIRate、 
APIBurst) 等 ， 这 些 逻 辑 说 明了 APIServer 是 按照 企业 级 平台 的 标准 所 设 
计 和 实现 的 。 


func NewAPIServer() *APIServer { 
s := APIServer{ 
InsecurePort: 8080, 
InsecureBindAddress: util.IP(net.ParseIP("127 


BindAddress: util.IP(net.ParseIP("0.0 


SecurePort: 6443, 


APIRate: 10.0, 

APIBurst: 200, 

APIPrefix: "/api", 

EventTTL: 1 * time.Hour, 
AuthorizationMode: "AlwaysAllow", 
AdmissionControl: "AlwaysAdmit", 
EtcdPathPrefix: master .DefaultEtcdPathPri 
EnableLogsSupport: true, 


MasterServiceNamespace: api.NamespaceDefault, 
ClusterName: "kubernetes", 


CertDirectory: "/var/run/kubernetes", 


RuntimeConfig: make(util.ConfigurationMap), 
KubeletConfig: client.KubeletConfig{ 

Port: ports.KubeletPort, 

EnableHttps: true, 

HTTPTimeout: time.Duration(5) * time.Second, 


ty 


return &s 


创建 了 APIServer 结 构 体 实例 后 ，apiserver.go 将 此 实例 传 入 子 包 
app/server.go 的 func (s*APIServer) Run (_[]string) 方法 里 ， 最 终 绑 定 
本 地 端口 并 创建 一 个 HTTP Server 与 一 个 HTTPS Server， 从 而 完成 整个 


进程 的 启动 过 程 。 


Run 方 法 的 代码 有 很 多 ， 这 里 就 不 再 列 出 源码 ， 对 该 方法 的 源码 解 
该 如 下 。 





(1) 调用 verifyClusterIPFlags 方 法 ， 验 证 ClusterIP 参 数 是 否 已 设置 
ERA 





(2) 验证 etcd-servers 的 参数 是 否 已 设置 。 


(3) 如 果 初 始 化 CloudProvider， 且 没有 CloudProvider 的 参数 ， 则 
志 告 警 并 继续 。 





(4) 根据 KubeletConfig 的 配置 参数 ， 调 用 pkg/Client/kubeclient.go 

中 的 方法 NewKubeletClient © 创建 一 个 kubelet Client 对 象 ， 这 其 实 是 一 

个 HITPKubeletClient 实 例 ， 目 前 只 用 于 kubelet 的 健康 检查 
(KubeletHealthChecker) 。 





(5) 判断 哪些 API Version 需 要 关闭 ， 目 前 在 1.0 代 码 中 默认 关闭 了 
vlbeta3 的 API 版 本 。 


(6) 创建 一 个 Kubernetes 的 RestClient 对 象 ， 具 体 的 代码 在 
pkg/client/helper.goH'TransportFor ( ) 方法 里 完成 ， 通 过 它 完 成 Pod、 
Replication Controller 及 Kubernetes Service 等 对 象 的 CRUD 操 作 。 


(7) 创建 用 于 访问 etcd Server 的 客户 端 ， 有 具体 代码 在 newEtcd ©) 
方法 里 实现 ， 从 代码 调用 中 可 以 看 出 ，Kubernetes 采 用 的 是 
github.comy/coreos/go-etcd/client.go 这 个 客户 端 实 现 。 


(8) 建立 鉴 权 (Authenticator) 、 授 权 (Authorizer) 、 服 务 许可 


框架 和 插件 (AdmissionControl) 的 相关 代码 逻辑 。 


(9) 获取 和 设置 APIServer 的 ExternalHost 的 名 称 ， 如 果 没 有 提供 
ExternalHost 参 数 ， 且 Kubernetes 运 行 在 谷歌 的 GCE 云 平台 上 ， 则 演 试 通 
过 CloudProvider 接 口 获取 本 机 节点 的 外 部 IP 地 址 。 


(10) 如 果 运 行 在 云 平 台中 ， 则 安装 本 机 的 SSH Key 到 Kubernetes 
集群 中 的 所 有 虚拟 机 上 。 


(11) 用 APIServer 的 数据 及 上 述 过 程 中 创建 的 一 些 对 象 
(KubeletClient、etcdClient、authenticator、admissionController 等 ) 作为 
参数 ， 构 造 Kubernetes Master 的 Config 结 构 (pkg/master/master.go) , 以 
此 生成 一 个 Master 实 例 ， 具 体 代码 在 master.go 中 的 New (c*Config) 77 
时 


(12) 用 上 述 创 建 的 Master 实 例 ， 分 别 创建 HITP Server 及 安全 的 
HTTPS Server 来 开始 监听 客户 端的 请 求 ， 至 此 整个 进程 启动 完毕 。 


6.2.2 ”关键 代码 分 析 


在 6.2.1 节 里 对 kube-apiserver 进 程 的 启动 过 程 进行 了 详细 分 析 ， 我 们 
发 现 Kubernetes API ”Service 的 关键 代码 就 隐藏 在 pkg/master/master.go 
里 ，APIServer 这 个 结构 体 只 不 过 是 一 个 参数 传递 通道 而 已 ， 它 的 数据 
最 终 传 给 了 pkg/master/master.go 里 的 Master 结 构 体 ， 下 面 是 它 的 完整 定 
X: 





// Master contains state for a Kubernetes cluster master. 
type Master struct { 
// "Inputs", Copied from Config 
serviceClusterIPRange *net.IPNet 


serviceNodePortRange util.PortRange 


cacheTimeout time.Duration 
minRequestTimeout time.Duration 

mux apiserver .Mux 
muxHelper *apiserver .MuxHelper 
handlerContainer *restful.Container 
rootWebService *restful.WebService 


enableCoreControllers bool 
enableLogsSupport bool 
enableUISupport bool 


enableSwaggerSupport bool 


enableProfiling bool 
apiPrefix string 


corsAllowedOriginList util.StringList 


authenticator authenticator .Request 
authorizer authorizer.Authorizer 
admissionControl admission.Interface 
masterCount int 

vibeta3 bool 

vi bool 


requestContextMapper api.RequestContextMapper 


// External host is the name that should be used in í 
externalHost string 

// clusterIP is the IP address of the master within 
clusterIP net.IP 

publicReadwritePort int 

serviceReadwriteIP net.IP 

serviceReadwritePort int 


masterServices *util.Runner 


// storage contains the RESTful endpoints exposed by 
storage map[string]rest.Storage 

// registries are internal client APIs for accessing 
// TODO: define the internal typed interface in a wa 
// also be replaced 

nodeRegistry minion.Registry 


namespaceRegistry namespace.Registry 


serviceRegistry service.Registry 
endpointRegistry endpoint .Registry 
serviceClusterIPAllocator service.RangeRegistry 
serviceNodePortAllocator service.RangeRegistry 
// "Outputs" 
Handler http.Handler 


InsecureHandler http.Handler 


// Used for secure proxy 


dialer apiserver.ProxyDialerFunc 
tunnels *util.SSHTunnelList 
tunnelsLock sync.Mutex 


installSSHKey InstallSSHKey 
lastSync int64 // Seconds since Epoch 
lastSyncMetric prometheus .GaugeFunc 


clock util.Clock 











在 这 段 代码 里 ， 除 了 之 前 我 们 熟悉 的 那些 变量 ， 又 多 了 几 个 陌生 的 
重要 变量 ， 接 下 来 我 们 逐一 对 其 进行 分 析 讲 解 。 





首先 是 类 型 为 apiserver.Mux 〈 来 自 文 件 pkg/apiserverapiserver.go ) 
的 mux 变 量 ， 下 面 是 对 它 的 定义 : 





// mux is an object that can register http handlers. 
type Mux interface { 


Handle(pattern string, handler http.Handler ) 


HandleFunc(pattern string, handler func(http.Responsew 


如 果 你 熟悉 Socket 编 程 ， 特 别 使 用 过 或 者 研究 过 HTTP ”Rest 的 一 些 


框 如 ， 那 么 对 于 这 个 Mux 接 口 就 再 熟悉 不 过 了 ， 生 是 一 个 HTTP 的 多 分 
器 (Multiplexer) ， 其 实 它 也 是 Golang HTTP 基 础 包 里 的 http.ServeMux 
的 一 个 接口 子 集 ， 用 于 派发 (Dispatch) 某 个 Request 路 径 〈 这 里 用 
pattern 变 量 表示 ) 到 对 应 的 http.Handler 进 行 处 理 。 实 际 上 在 master.go 代 
码 中 是 生成 一 个 http.ServeMux 对 象 并 赋值 给 apiserver.Mux 变 量 ， 在 代码 
中 还 有 强制 类 型 转换 的 语句 。 从 上 述 分 析 来 看 ，apiserver.Mux 的 引入 是 
设计 的 一 个 败笔 ， 并 没有 增加 什么 价值 ， 反 而 增加 了 理解 代码 的 难度 。 
此 外 ， 为 了 更 好 地 实现 Rest 服 务 ，Kubernetes 在 这 里 引入 了 一 个 第 三 方 
的 REST 框 架 : github.com/emicklei/go-restful . 


go-restful 在 GitHub 上 有 36 个 贡献 者 ， 采 用 了 “路 由 ”映射 的 设计 思 
并 且 在 API 设 计 中 使 用 了 流行 的 Fluent Style 风格 ， 使 用 起 来 柄 畅 淋 
也 难怪 Kubernetes 选 择 了 它 。 下 面 是 go-restful 的 优 民 特性 。 


Ruby on Rails 风 格 的 Rest 路 由 映射 ， 例 
如 /people/{person_id}/groups/{fgroup_id} 。 

大 大 简化 了 Rest API 的 开发 工作 。 

底层 实现 采用 Golang 的 HTTP 协议 栈 ， 几 乎 没有 限制 。 

拥有 完整 的 单元 包 代 码 ， 很 容易 开发 一 个 可 测试 的 Rest API. 

Google AppEngine ready。 


go-restful 框 架 中 的 核心 对 象 如 下 。 


restful.Container: 代表 一 个 HTTP Rest 服 务 器 ， 包 括 一 组 


restful.WebService 对 象 和 一 个 http.ServeMux 对 象 ， 使 用 

RouteSelector 进 行 请 求 派 发 。 

restful.WebService: 表示 一 个 Rest 服 务 ， 由 多 个 Rest 路 由 
Crestful.Route) 组 成 ， 这 一 组 Rest 路 由 共享 同一 个 Root Path. 

restful.Route: 表示 一 个 Rest 路 由 ，Rest 路 由 主要 由 Rest Path、HTTP 

Method、 输 入 输出 类 型 (HTML/JSON) 及 对 应 的 回调 函数 

restful.RouteFunction 组 成 。 

e restful.RouteFunction: 一 个 用 于 处 理 具 体 的 REST 调 用 的 函数 接口 定 

义 ， 具 体 定义 为 type RouteFunction func (*Request, *Response) 。 


Master 结 构 体 里 包含 了 对 restful.Container 与 restful.WebService 这 两 
个 go-restful 核 心 对 象 的 引用 ， 在 接 下 来 的 Master 对 象 的 构造 方法 中 (对 
应 代码 为 master.go 的 func New (c*Config) *Master) 被 初始 化 。 那 么 ， 
问题 又 来 了 ，Kubernetes 的 这 么 一 堆 Rest API 又 是 在 哪里 定义 的 ， 是 如 何 
被 绑 定 到 restful.Route 里 的 呢 ? 











要 理解 这 个 问题 ， 我 们 要 首先 弄 清 楚 Master 结 构 体 中 的 变量 : 
storage map[string]rest.Storage 


storage 变 量 是 一 个 Map，Key 为 Rest API 的 path，Value 为 rest.Storage 
接口 ， 此 接口 是 一 个 通用 的 符合 Restful 要 求 的 资源 存储 服务 接口 ， 每 个 
服务 接口 负责 处 理 一 类 (Kind) Kubernetes Rest API 中 的 数据 对 象 一 一 
资源 数据 ， 只 有 一 个 接口 方法 : New O ，New O 方法 返回 该 Storage 
服务 所 能 识别 和 管理 的 某 种 具体 的 资源 数据 的 一 个 空 实 例 。 


type Storage interface { 


New() runtime.Object 


在 运行 期 间 ，Kubernetes API Runtime 运 行 时 框架 会 把 New O) 方法 
返回 的 空 对 象 的 指针 传 入 Codec.DecodeInto ([]byte, runtime.Object) 77 
法 中 ， 从 而 完成 HTTP Rest 请 求 中 的 Byte 数 组 反 序列 化 逻辑 。Kubernetes 
API ”Server 中 所 有 对 外 提供 服务 的 Restful 资 源 都 实现 了 此 接口 ， 这 些 资 
源 包括 pods、bindings、podTemplates、replicationControllers、services 
等 ， 完 整 的 列表 就 在 master.go 的 func (m*Master) init (Cc*Config) F, 
下 面 是 相关 代码 请 段 〈 截 取 部 分 代码 ) 。 


m.storage = map[string]rest.Storage{ 


"pods": podStorage.Pod, 
"pods/status": podStorage.Status, 
"nods/log": podStorage.Log, 
"pods/exec": podStorage.Exec, 


"pods/portforward": podStorage.PortForward, 


"pods/proxy": podStorage.Proxy, 
"nods/binding": podStorage.Binding, 
"bindings": podStorage. Binding, 


"podTemplates": podTemplateStorage, 


"replicationControllers": controllerStorage, 
"services": service.NewStorage(m. si 
"endpoints": endpointsStorage, 


"minions": nodeStorage, 








看 到 上 面 这 段 代码 ， 你 在 潜意识 里 已 经 明白 ， 这 其 实 就 是 似曾相识 
的 Kubernetes Rest API 列 表 ，storage 这 个 Map 的 Key 束 是 Rest API 的 访问 
路 径 ，Value 却 不 是 之 前 说 好 的 restful.Route。 聪 明 的 你 一 定 想 到 了 答 
R: 必然 存在 一 个 “转换 适 配 ” 的 方法 来 实现 上 述 转换 ! 这 段 不 难 理解 但 
源码 超 长 的 方法 就 在 pkg/apiserver/api_installer.go 的 下 述 方法 里 : 


func (a *APIInstaller) registerResourceHandlers(path str 


上 述 方法 把 一 个 path 对 应 的 rest.Storage 转 换 成 一 系列 的 restful.Route 
并 添加 到 指针 restful.WebService 中 。 这 个 函数 的 代码 之 所 以 很 长 ， 是 因 
为 有 各 种 情况 要 考虑 ， 比 如 pods/portforward 这 种 路 径 要 处 理 child， 还 要 
判断 每 种 的 Storage 资 源 类 型 所 文 持 的 操作 类 型 ， 比 如 是 否 文 持 create、 
delete、update 及 是 否 文 持 list、watch、patcher 操 作 等 ， 对 各 种 情况 都 考 
虑 以 后 ， 这 个 函数 的 代码 量 已 接近 500 行 ! 估计 Kubernetes 这 段 代码 的 作 
者 也 不 大 好 意思 ， 于 是 外 面 封装 了 简单 函数 : func (a*APIInstaller) 
Install， 内 部 循环 调用 registerResourceHandlers， 返 回 最 终 的 
restful.WebService 对 象 ， 此 方法 的 主要 代码 如 下 : 


// Installs handlers for API resources. 
func (a *APIInstaller) Install() (ws *restful.WebService 
// Register the paths in a deterministic (sorted) or 
paths := make([]string, len(a.group.Storage) ) 
var i int = 0 
for path := range a.group.Storage { 
paths[i] = path 


i++ 


sort.Strings(paths) 
for _, path := range paths { 
if err := a.registerResourceHandlers(path, a.gro 


errors = append(errors, err) 


} 


return ws, errors 


为 了 区 分 API 的 版 本 ， 在 apiserver.go 里 定义 了 一 个 结构 体 : 
APIGroupVersion。 以 下 是 其 代码 : 


type APIGroupVersion struct { 
Storage map[string]rest.Storage 
Root string 
Version string 
// ServerVersion controls the Kubernetes APIVersion 
// schema like api.Status, api.DeleteOptions, and ap 
// define a version "vibetai" but want to use the Kul 
// empty, defaults to Version. 


ServerVersion string 
Mapper meta.RESTMapper 
Codec runtime.Codec 


Typer runtime.ObjectTyper 


Creater runtime.ObjectCreater 


Convertor runtime.ObjectConvertor 


Linker runtime.SelfLinker 


Admit admission. Interface 


Context api.RequestContextMapper 


ProxyDialerFn ProxyDialerFunc 


MinRequestTimeout time.Duration 


我 们 注意 到 APIGroupVersion 是 与 rest.Storage Map 捆 绑 的 ， 并 且 绑 定 
了 相应 版 本 的 Codec、Convertor 用 于 版 本 转换 ， 这 样 束 很 容易 理解 
Kubernetes 是 怎样 区 分 多 版 本 API 的 Rest 服 务 的 。 以 下 是 过 程 详 解 。 


首先 ， 在 APIGroupVersion 的 
Install]REST (container*restful.Container) 方法 里 ， 用 Version 变 量 来 构造 
一 个 Rest API Path 前 级 并 赋值 给 APIINstaller 的 prefix 变 量 ， 并 调用 它 的 
Install O 方法 完成 Rest API 的 转换 ， 代 码 如 下 : 


func (g *APIGroupVersion) InstallREST(container *restful 
info := &APIRequestInfoResolver{util.NewStringSet(string 
prefix := path.Join(g.Root, g.Version) 


installer := &APIInstaller{ 


group: g, 
info: info, 
prefix: prefix, 


minRequestTimeout: g.MinRequestTimeout, 


proxyDialerFn: g.ProxyDialerFn, 
} 
ws, registrationErrors := installer.Install() 


container .Add(ws) 


接着 ， 在 APIInstaller 的 Install O 方法 里 用 prefix (API 版 本 〉 前 级 
生成 WebService 的 相对 根 路 径 : 


func (a *APIInstaller) newWebService() *restful.WebServi 

ws := new(restful.WebService) 

ws.Path(a.prefix) 

ws.Doc("API at"+ a.prefix +"version"+ a.group.Version) 
// TODO: change to restful.MIME_JSON when we set con 
ws .Consumes("*/*") 
ws.Produces(restful.MIME_ JSON) 


ws .ApiVersion(a.group.Version) 


return ws 


最 后 ， 在 Kubernetes 的 Master 初 始 化 方法 func (m*Master ) 
init (c*Config) 里 生成 不 同 的 APIGroupVersion 对 象 ， 并 调用 
InstallRest O 方法 ， 完 成 最 终 的 多 版 本 API 的 Rest 服 务 装 配 流程 : 


if m.vibeta3 { 
if err := m.api_vibeta3().InstallLREST(m.handlerC 


glog.Fatalf("Unable to setup API vibeta3: %v 


} 
apiVersions = append(apiVersions, "vibeta3") 
} 
if m.vi { 
if err := m.api_v1().InstallREST(m.handlerContai 
glog.Fatalf("Unable to setup API vi: %v", er 
} 


apiVersions = append(apiVersions, "v1") 





至 此 ，Rest API 的 多 版 本 问题 还 有 最 后 一 个 需要 澄清 ， 即 在 不 同 的 
版 本 中 接口 的 输入 输出 参数 的 格式 是 有 差别 的 ，Kubernetes 是 怎么 处 理 
这 个 问题 的 ? 


要 和 弄 明 白 这 一 点 ， 我 们 首先 要 研究 KubernetesAPI 里 的 数据 对 象 的 序 
列 化 、 反 序列 化 的 实现 机 制 。 为 了 同时 解决 数据 对 象 的 序列 化 、 反 序列 
化 与 多 版 本 数据 对 象 的 兼容 和 转换 问题 ，Kubernetes 设 计 了 一 套 复杂 的 
机 制 ， 首 先 ， 它 设计 了 conversion.Scheme 这 个 结构 体 

(pkg/conversion/schema.go 里 ) ， 以 下 是 对 它 的 定义 : 


// Scheme defines an entire encoding and decoding scheme 
type Scheme struct { 
// versionMap allows one to figure out the go type o 
versionMap map[string]map[string]reflect.Type 
// typeToVversion allows one to figure out the versio 
// is registered for multiple versions, the last one 


typeToVersion map[reflect.Type]string 


// typeToKind allows one to figure out the desired " 
typeToKind map[reflect.Type][]string 

// converter stores all registered conversion functi 
converter *Converter 

// cloner stores all registered copy functions. It a 
// deep copy behavior. 


cloner *Cloner 


// Indent will cause the JSON output from Encode to 
Indent bool 

// InternalVersion is the default internal version. 
// you use "" for the internal version. 
InternalVersion string 

// MetaInsertionFactory is used to create an object 
// the version and kind information for all objects. 


MetaFactory MetaFactory 


在 上 述 代 和 码 中 可 以 看 到 ，typeToVersion 与 versionMap 属 性 是 为 了 解 
决 数据 对 象 的 序列 化 与 反 序列 化 问题 ，converter 属 性 则 负责 不 同 版 本 的 
数据 对 象 转换 问题 ，Kubernetes 这 个 设计 思路 简单 方便 地 解决 了 多 版 本 
的 序列 化 和 数据 转换 问题 ， 不 得 不 赞 ! 下 面 是 conversion.Scheme 里 序列 
化 、 反 序列 化 的 核心 方法 NewObject © 的 代码 : 通过 查找 versionMap 
里 匹配 的 注册 类 型 ， 以 反射 方式 生成 一 个 空 的 数据 对 象 : 





func (s *Scheme) NewObject(versionName, kind string) (in 


if types, ok := s.versionMap[versionName]; ok { 


if t, ok types[kind]; ok { 


return reflect.New(t).Interface(), nil 


} 


return nil, &notRegisteredErr{kind: kind, versio 


} 


return nil, &notRegisteredErr{kind: kind, version: v 


而 pkg/conversion/encode.go 与 decode.go 则 在 conversion.Scheme 提 供 
的 基础 功能 之 上 ， 完 成 了 最 终 的 序列 化 、 反 序列 化 功能 。 下 面 是 
encode.go 里 的 主 方法 EncodeToVersion (..) 的 关键 代码 片段 : 














// 确 定 要 转换 的 源 对 象 的 版 本 号 和 类 别 

objVersion, objKind, err := s.ObjectVersionAndKind(obj ) 
// 生 成 目标 版 本 的 空 对 象 

objOut, err := s.NewObject(destVersion, objKind) 

// 生 成 转换 过 程 中 所 需 的 Metadata 信 息 

flags, meta := s.generateConvertMeta(objVersion, destVer 
// 调 用 converter 的 方法 将 源 对 象 的 数据 填充 到 目标 对 象 objOut 

err = s.converter.Convert(obj, objOut, flags, meta) 

// 用 JSON 将 目标 对 象 转换 成 byte[] 数 组 ， 完 成 序列 化 过 程 


data, err = json.Marshal(obj) 

















再 进一步 ，Kubernetes 在 conversion.Scheme 的 基础 上 又 做 了 一 个 封 
装 工 具 类 runtime.Scheme， 可 以 看 作 前 者 的 代理 类 ， 主 要 增加 了 
fieldLabelConversionFuncs 这 个 Map 属 性 ， 用 于 解决 数据 对 象 的 属性 名 称 
的 兼容 性 转换 和 校 验 ， 比 如 将 需要 兼容 Pod 的 spec.host 属 性 改 为 
spec.nodeName 的 情况 。 


注意 到 conversion.Scheme 只 是 实现 了 一 个 序列 化 与 类 型 转换 的 框架 


API， 提 供 了 注册 资源 数据 类 型 与 转换 函数 的 功能 ， 那 么 具体 的 资源 数 
据 对 象 类 型 、 转 换 函 数 又 是 在 哪个 包 里 实现 的 呢 ? 答案 是 pkg/api。 
Kubernetes 为 不 同 的 API 版 本 提供 了 独立 的 数据 类 型 和 相关 的 转换 函数 并 





按照 版 本 号 命名 Package， 如 pkg/apiv1、pkg/api/vlbeta3 等 ， 而 当前 默认 
版 本 《内 部 版 本 ) 则 存在 于 pkg/api 目 录 下 。 


以 pkg/api/v1 为 例 ， 在 每 个 目录 里 都 包括 如 下 关键 源码 : 


types.go 定 义 了 Rest ”API 接口 里 所 涉及 的 所 有 数据 类 型 ，v1 版 本 有 
2000 行 代码 ; 

在 conversion.go 与 conversion_generated.go 里 定义 了 
conversion.Scheme 所 和 需 的 从 内 部 版 本 到 v1 版 本 的 类 型 转换 函数 ， 其 
中 conversion_generated.go 中 的 代码 有 5000 行 之 多 ， 当 然 这 是 通过 工 
有 共 自 动 生 成 的 代 但 ; 

register.go 人 负责 将 types.go 里 定义 的 数据 类 型 与 conversion.go 里 定义 
的 数据 转换 函数 注册 到 runtime.Schema 里 。 


pkg/api 里 的 register.go 初 始 化 生成 并 持 有 一 个 全 局 的 runtime.Scheme 


对 象 ， 并 将 当前 默认 版 本 的 数据 类 型 (pkg/api/types.go) 注册 进去 ， 相 
关 代 码 如 下 : 


var Scheme = runtime.NewScheme() 
func init() { 
Scheme . AddKnownTypes("", 
&Pod{}, 
&PodList{}, 
&PodStatusResult{}, 


&PodTemplate{}, 
&PodTemplateList{}, 
&ReplicationControllerList{}, 
// 此 次 省 略 30 多 个 数据 类 型 
&ServiceList{}, 
&Service{}, 
&NodeList{}, 
&Node{}, 
// 省 略 


而 pkg/api/vlregister.go 与 vIbeta3 下 的 register.go 在 初始 化 过 程 中 分 
别 把 与 版 本 相关 的 数据 类 型 和 转换 函数 注册 到 全 局 的 runtime.Scheme 
中 : 


func init() { 
// Check if vi is in the list of supported API versi 
if !registered.IsRegisteredAPIVersion("vi") { 


return 


// Register the API. 
addKnownTypes( ) 
addConversionFuncs( ) 


addDefaultingFuncs( ) 


这 样 一 来 ， 其 他 地 方 都 可 以 通过 runtime.Scheme 这 个 全 局 变量 来 完 


成 Kubernetes API 中 的 数据 对 象 的 序列 化 和 反 序 列 化 还 辑 了 ， 比 如 
Kubernetes API Client 包 就 大 量 使 用 了 它 ， 下 面 是 pkg/client/pods.go 里 Pod 
删除 的 Delete〈) 方法 的 代码 : 


// Delete takes the name of the pod, and returns an erro 
func (c *pods) Delete(name string, options *api.DeleteOp 
// TODO: to make this reusable in other client libra 
if options == nil { 
return c.r.Delete().Namespace(c.ns).Resource("po 
} 
body, err := api.Scheme.EncodeToVersion(options, c.r 
if err != nil { 
return err 


} 


return c.r.Delete().Namespace(c.ns).Resource("pods" ) 


清楚 了 Kubernetes Rest API 中 的 数据 对 象 的 序列 化 机 制 及 多 版 本 的 
实现 原理 之 后 ， 我 们 接着 分 析 下 和 面 这 个 重要 流程 的 实现 细节 。 


Kubernetes 中 实现 了 rest.Storage 接 口 的 服务 在 转换 成 
restful.RouteFunction 以 后 ， 是 怎样 处 理 一 个 Rest 请 求 并 最 终 完成 基于 后 
端 存储 服务 etcd 上 的 具体 操作 过 程 的 ? 














首先 ，Kubernetes 设 计 了 一 个 名 为 “注册 表 ” 的 
Package (pkg/registry) ， 这 个 Package 按 照 rest.Storage 服 务 所 管理 的 资 
源 数据 的 类 型 而 划分 为 不 同 的 子 包 ， 每 个 子 包 都 由 相同 命名 的 一 组 
Golang 代 人 码 来 完成 具体 的 Rest 接 口 的 实现 逻辑 。 


下 面 我 们 以 Pod 的 Rest 服 务实 现 为 例 ， 其 与 “注册 表 ” 相 关 的 代码 位 
于 pkg/registry/pod 中 ， 在 registry.go 里 定义 了 Pod 注 册 表 服务 的 接口 : 


type Registry interface { 
// ListPods obtains a list of pods having labels whi 
ListPods(ctx api.Context, label labels.Selector) (*a 
// Watch for new/changed/deleted pods 
WatchPods(ctx api.Context, label labels.Selector, fi 
// Get a specific pod 
GetPod(ctx api.Context, podID string) (*api.Pod, err 
// Create a pod based on a specification. 
CreatePod(ctx api.Context, pod *api.Pod) error 
// Update an existing pod 
UpdatePod(ctx api.Context, pod *api.Pod) error 
// Delete an existing pod 


DeletePod(ctx api.Context, podID string) error 


} 


我 们 看 到 这 个 Pod 注 册 表 服务 是 针对 Pod 的 CRUD 的 操作 接口 的 一 个 
定义 ， 在 入 口 参 数 中 除了 调用 的 上 下 文 环境 api.Context， 束 是 我 们 之 前 
分 析 过 的 pkg/api 包 中 的 Pod 这 个 资源 数据 对 象 。 为 了 实现 强 类 型 的 方法 
调用 ， 在 registry.go 里 定义 了 一 个 名 为 storage 的 结构 体 ，storage 实 现 
Registry 接 口 ， 可 以 看 作 一 种 代理 设计 模式 ， 因 为 具体 的 操作 都 是 通过 
内 部 rest.StandardStorage 来 实现 的 。 下 面 是 截取 的 registry.go 中 的 create、 
update、delete 的 源码 : 








func (s *storage) CreatePod(ctx api.Context, pod *api.Po 


_, err := s.Create(ctx, pod) 


return err 


func (s *storage) UpdatePod(ctx api.Context, pod *api.Po 
_, _, err := s.Update(ctx, pod) 


return err 


func (s *storage) DeletePod(ctx api.Context, podID strin 
_, err := s.Delete(ctx, podID, nil) 


return err 


那么 ， 这 个 实现 了 rest.StandardStorage 通 用 接口 的 真正 Storage 又 是 
什么 ?从 Master 对 象 的 初始 化 函数 中 ， 我 们 发 现 了 下 面 的 相关 代码 : 


func (m *Master) init(c *Config) { 
healthzChecks := []healthz.HealthzChecker {} 
m.clock = util.RealClock{} 
podStorage := podetcd.NewStorage(c.EtcdHelper, c.Kub 


podRegistry := pod.NewRegistry(podStorage. Pod) 


Master 对 象 创建 了 一 个 私有 变量 podStorage， 其 类 型 为 
PodStorage (pkg/registry/pod/etcd/etcd.go) ，Pod 注 册 表 服务 实例 
(podRegistry) 里 真正 的 Storage 是 podStorage.Pod。 下 面 是 podetcd 的 函 
数 NewStorage 中 的 关键 代码 : 


func NewStorage(h tools.EtcdHelper, 


store := &etcdgeneric.Etcd{ 


k client.Connectionli 


NewFunc: 


NewListFunc: 


return PodStorage{ 
Pod: 
Binding: 
Status: 
Log: 
Proxy: 


Exec: 


PortForward: &PortForwardREST{store: 


在 上 述 代 码 中 我 们 看 到 : 


func() runtime.Object { return &api 


func() runtime.Object { return &api 


&REST{*store}, 


&BindingREST{store: store}, 


&StatusREST{store: &statusStore}, 


&LOgREST{store: store, kubeletConn: 


&ProxyREST{store: store}, 


&ExecREST{store: store, kubeletConn 


store, kube. 


fi + pkg/registry/generic/etcd/etcd.go # VJ 


ne 是 真正 的 Snags R 。 而 具体 操作 etcd 的 代码 是 人 靠 tools.EtcdHelper 


完成 的 ， 


通过 分 析 etcd.go 里 的 func (e*Etcd) Create (ctx 


api.Context，obj runtime.Object) 方法 ， 我 们 知道 创建 一 个 etcd 里 的 键 值 


对 的 关键 逻辑 如 下 。 


。 获取 对 象 的 名 字 : name, err: 


e 获取 Key: key, err: 
生成 二 


空 的 Object 对 象 : out: 


=e.ObjectNameFunc (obj) 。 


=e.KeyFunc (ctx, name) 。 


=e.NewFunc () à 


。 将 键 值 对 写 入 etcd: fEe.Helper.CreateObj (key, obj, out, ise 方 


法 中 通过 调用 runtime.Codec 完 成 从 对 象 到 字符 串 的 转换 ， 


到 etcd 中 。 


终 保存 


。 回调 创建 完成 后 的 处 理 逻 辑 : e.AfterCreate Cout) 。 


注意 到 之 前 PodStorage 创 建 store 时 重 载 了 ObjectNameFunc () 、 
KeyFunc () . NewFunc O 等 函数 ， 于 是 完成 了 针对 Pod 的 创建 过 程 ， 
Kubernetes API 服 务 中 的 其 他 数据 对 象 也 都 遵循 同样 的 设计 模式 。 


进一步 研究 代码 ， 我 们 发 现 PodStorage 中 的 Pod、Binding、Status 等 
属性 是 pkg/api/rest/rest.go 中 几 个 不 同 的 Rest 接 口 的 实现 ， 并 且 通 过 
etcdgeneric.Etcd 这 个 实例 来 完成 Pod 的 一 些 具 体操 作 ， 比 如 这 里 的 
StatusREST。 下 面 是 其 相关 代码 片段 : 





// StatusREST implements the REST endpoint for changing 
type StatusREST struct { 
store *etcdgeneric.Etcd 
} 
// New creates a new pod resource 
func (r *StatusREST) New() runtime.Object { 
return &api.Pod{} 
} 
// Update alters the status subset of an object. 
func (r *StatusREST) Update(ctx api.Context, obj runtime 


return r.store.Update(ctx, obj) 


表 6.2 展 现 了 PodStorage 中 的 各 个 XXXREST 接 口 与 pkg/api/rest/rest.go 
里 的 相关 Rest 接 口 的 一 一 对 应 关系 。 


表 6.2 ”PodStorage 中 的 各 个 XXXREST 接 口 与 


pkg/api/rest/rest.go 里 的 相关 Rest 接 口 的 一 一 对 应 关系 


PodStorage Rest 接口 对 应 API Rest 框架 的 接口 接口 功能 
rest.Redirector 重 定向 资源 的 路 径 
rest.CreaterUpdater 资源 创建 、 更 新 接口 
rest.Lister 资源 列表 查询 接口 

rest. Watcher Watcher 资源 变化 接口 
rest. GracefulDeleter 支持 延迟 的 资源 删除 接口 
rest.Getter 获取 具体 资源 的 信息 接口 








BindingREST rest.Creater 创建 资源 的 接 








m | 
StatusREST Rest.Updater 更 新 资源 的 接口 
O 


LogREST rest.GetterWithOptions 获取 资源 的 接 











ExecREST\ProxyREST\ PortForwardREST rest.Connecter 连接 资源 的 接口 











其 中 PodStorage.REST 接 口 究竟 实现 了 哪些 API Rest 接 口 ， 这 个 比较 
隐 上 临 ， 笔 者 也 花费 了 一 些 时 间 来 研究 这 个 问题 ， 这 涉及 Go 语言 的 一 个 
特殊 特性 : 结构 体内 组 一 个 其 他 类 型 的 结构 体 指 针 ， 就 可 以 使 用 内 共 结 
构 体 的 方法 ， 相 当 于 面向 对 象 语 言 中 的 “继承 ”。 而 PodStorage.REST 恰 恰 
仍 套 了 etcdgeneric.Etcd 类 型 的 匿名 指针 : &REST{*store}, MI 
etcdgeneric.Etcd 则 实现 了 rest.Creater、rest.Lister、rest.Watcher 等 资源 管 
理 接口 的 所 有 方法 ，PodStorage.REST 也 “继承 ”了 这 些 接 口 。 


我 们 回头 看 看 下 面 这 段 来 自 api_installer.go 的 
registerResourceHandlers 函 数 中 的 片段 : 


creater, isCreater := storage.(rest.Creater ) 
namedCreater, isNamedCreater := storage. (rest .NamedC 
lister, isLister := storage.(rest.Lister) 

getter, isGetter := storage.(rest.Getter) 


getterwithOptions, isGetterWithOptions := storage.(r 
deleter, isDeleter := storage.(rest.Deleter ) 


gracefulDeleter, isGracefulDeleter := storage.(rest.'| 


updater, isUpdater := storage.(rest.Updater ) 
patcher, isPatcher := storage.(rest.Patcher ) 
watcher, isWatcher := storage.(rest.Watcher ) 
_, isRedirector := storage.(rest.Redirector ) 
connecter, isConnecter := storage.(rest.Connecter ) 


storageMeta, isMetadata := storage.(rest.StorageMeta 


上 述 代 人 码 对 storage 对 象 进行 判断 ， 以 确定 并 标记 它 所 满足 的 
APIRest 接 口 类 型 ， 而 接 下 来 的 这 段 代 人 码 在 此 基础 上 确定 此 接口 所 包含 
的 actions， 后 者 则 对 应 到 某 种 HTTP 请 求 方法 
(GET/POST/PUT/DELETE) 或 者 HTTP PROXY. WATCH, 
CONNECT 等 动作 : 





ctions = appendIf(actions, action{"GET", itemPath, nameP 
actions = appendIf(actions, action{"PATCH", itemPath, na 
actions = appendIf(actions, action{"DELETE", itemPath, n 
actions = appendIf(actions, action{"WATCH", "watch/" + i 
actions = appendIf(actions, action{"PROXY", "proxy/" + i 


actions = appendIf(actions, action{"CONNECT", itemPath, 


我 们 注意 到 rest.Redirector 类 型 的 storage 被 当 作 PROXY 进 行 处 理 ， 由 
apiserver.ProxyHandler 进 行 拦 截 ， 并 调用 rest.Redirector 的 
ResourceLocation 方 法 获取 到 资源 的 处 理 路 径 〈 可 能 包括 一 个 非 空 的 
http.RoundTripper， 用 于 处 理 执行 Redirector 返 回 的 URL 请 求 ) 。 
Kubernetes API Server 中 PROXY 请 求 存 在 的 意义 在 于 透明 地 访问 其 他 某 
个 节点 《比如 某 个 Minion) 上 的 API。 





最 后 ， 我 们 来 分 析 下 registerResourceHandlers 中 完成 从 rest.Storage 到 
restful.Route 映 射 的 最 后 一 段 关键 代码 。 下 面 是 rest.Getter 接 口 的 Storage 
的 映射 代码 : 


case "GET": // Get a resource. 

var handler restful.RouteFunction 

handler = GetResource(getter, reqScope) 

doc := "read the specified " + kind 

route := ws.GET(action.Path).To(handler).Filter(m).Doc(d 
Param(ws.QueryParameter("pretty", "If 'true', then the o 
Operation("read"+namespaced+kind+strings.Title(subresour 
Produces(append(storageMeta.ProducesMIMETypes(action.Ver 


Returns(http.StatusOK, "OK", versionedObject).Writes(ver 


addParams(route, action.Params) 


ws .Route(route) 


上 述 代 码 首 先 通过 函数 GetResource () 创建 了 一 个 
restful.RouteFunction， 然 后 生成 一 个 restful.route 对 象 ， 最 后 注册 到 
restful.WebService 中 ， 从 而 完成 了 rest.Storage 到 Rest 服 务 的 “最 后 一 公 
里 ”通车 。GetResource〈) 冰 数 存在 于 pkg/apiserver/resthandler.go 里 ， 
resthandler.go 提 供 了 各 种 具体 的 restful.RouteFunction 的 实现 函数 ， 是 真 
正 触 发 rest.Storage 调 用 的 地 方 。 下 面 是 GetResource() 方法 的 主要 代 
人 码 ， 可 以 看 出 这 里 是 调用 rest.Getter 接 口 的 Get() 方法 以 返回 某 个 资源 
WR: 


func GetResource(r rest.Getter, scope RequestScope) rest 


return getResourceHandler (scope, 
func(ctx api.Context, name string, req *restful. 
return r.Get(ctx, name) 


}) 


看 了 上 面 的 代码 ， 你 可 能 会 有 一 个 疑问 : “说 好 的 权限 控制 呢 ? HY 
急 ， 看 看 下 面 的 资源 创建 的 createHandler〈() 代码 : 


if admit.Handles(admission.Create) { 
userInfo, _ := api.UserFrom(ctx) 
err = admit.Admit(admission.NewAttributesRec 
if err != nil { 


errorJSON(err, scope.Codec, w) 


return 


资源 的 Update、Delete、Connect、Patch 等 操作 都 有 类 似 的 权限 控 
制 ， 从 Admit 的 参数 admission.Attributes 的 属性 来 看 ， 第 三 方 系 统 可 以 开 
发 细 料 上 度 的 权限 控制 插件 ， 针 对 任意 资源 的 任意 属性 进行 细 粒 度 的 权限 
控制 ， 因 为 资源 对 象 本 号 都 传递 到 参数 中 了 。 





对 Kubernetes Rest API Server 的 复杂 实现 机 制 和 调用 流程 的 总 结 如 


sty =H 


Ps 


e 在 pkg/api 包 里 定义 了 Rest ”API 中 涉及 的 资源 对 象 、 提 供 的 Rest 接 
口 、 类 型 转换 框架 和 有 具体 转换 函数 、 序 列 化 反 序 列 化 等 代码 。 其 


中 ， 资 源 对 象 和 转换 函数 按照 版 本 分 包 ， 形 成 了 Kubernetes API 
Server 基 础 的 框架 ， 其 中 核心 是 各 类 资源 (如 Node、Pod、 
PodTemplate、Service 等 ) 及 这 些 资源 对 应 的 rest.Storage (Rest API 
接口 ) 。 

在 pkg/runtime 包 里 最 重要 的 对 象 是 Schema， 它 保存 了 Kubernetes 
API Service 中 注册 的 资源 对 象 类 型 、 转 换 函 数 等 重要 基础 数据 。 另 
外 ，runtime 包 也 提供 了 获取 json/yaml 序 列 化 、 反 序列 化 的 Codec 结 
构 体 ，runtime 总 体 上 与 pkg/api 密 切 关 联 ， 分 离 出 来 的 目的 是 供 其 他 
模块 方便 使 用 。 

pkg/registry 包 其 实 是 把 pkg/api 中 定义 的 各 种 资源 对 象 所 提供 的 Rest 
接口 进一步 规范 定义 并 且 实 现 对 应 的 接口 ， 其 中 
generate/etcd/etcd.go 里 的 etcd 对 象 是 一 个 真正 实现 了 rest.Storage 接 口 
的 基于 etcd 后 端 存储 的 服务 框架 ， 并 且 Kubernetes 中 的 各 种 资源 对 
象 的 具体 Storage 实 现 也 是 通过 它 来 完成 真正 的 “后 端 存储 操作 ”。 
Kubernetes 采 用 了 go-restful 这 个 第 三 方 的 Rest 框 架 ， 大 大 人 简化 了 Rest 
服务 的 开发 ， 主 要 代码 在 pkg/apiserver 源 码 包 里 。 通 过 
APIGroupVersion 这 个 结构 体 可 完成 不 同 API 版 本 的 Rest 路 径 上 映射， 

而 api_installer.go 则 实现 了 从 Kubernetes Rest.Storage 接 口 到 go-restful 
的 映射 连接 逻辑 ， 对 应 rest.Storage 的 具体 restful.RouteFunction 则 在 
resthandler.go 里 实现 。 











6.2.3 Wiese 


如 末 你 耐心 看 完了 上 面 的 每 一 段 文字 和 代码 ， 而 且 符 试 奶 踪 源 码 来 
加 深 对 6.2.1 节 内 容 的 理解 ， 那 么 笔者 相信 你 对 于 Kubernetes API Server 
的 设计 的 第 一 个 评价 束 是 :“ 太 复杂 、 太 反常 了 ! 不 就 是 一 个 Rest Server 
么 ， 如 果 用 Java 语 言 ， 我 可 以 分 分 钟 搞定 一 个 ! ”当然 ， 你 肯定 有 以 下 
或 者 更 多 的 假设 。 





。 放弃 多 版 本 API 的 兼容 需求 。 

只 采用 一 个 特定 的 后 端 存储 实现 。 

API 只 接收 一 种 输入 输出 格式 ， 比 如 JSON 或 者 YAML， 而 不 是 两 种 
或 更 多 。 

放弃 Watch 这 种 高 难度 的 API。 

不 实现 Proxy 代 理 。 

不 做 可 拔 插 的 权限 控制 设计 《或 者 根本 没有 ) 。 

每 新 增 一 种 资源 类 型 ， 就 从 头 写 很 多 代码 来 实现 该 资源 的 Rest 服 
务 。 


虽然 代码 很 复杂 ， 但 我 们 不 得 不 承认 ，Kubernetes API Server 是 一 
个 精心 “设计 ”的 系统 。 





什么 样 的 设计 是 一 个 好 的 设计 ?这 个 问题 没有 标准 答案 ， 但 有 一 点 
是 大 家 都 认可 的 : 好 的 设计 要 尽量 提供 一 种 好 的 框架 机 制 ， 方 便 未 来 增 
加 新 功能 或 者 自 定 义 扩 展 某 些 特性 。 我 们 以 这 个 标准 对 Kubernetes API 
Server 的 设计 进行 评价 ， 就 会 友 现 : 它 的 设计 真 的 很 好 。 








我 们 先 分 析 一 下 Kubernetes API Server 的 “领域 模型 ”。API Server 里 
的 Rest 服 务 都 是 针对 某 个 “资源 对 象 * 的 操作 ， 这 些 操作 可 以 分 为 新 增 、 
修改 、 列 表 输 出 、 删 除 、Watch 变 化 、 代 理 请 求 及 连接 资源 等 基础 操 
作 ， 大 多 数 操作 都 是 与 后 端 存储 的 交互 。 因 为 只 是 基本 的 资源 数据 对 象 
的 增 、 删 、 改 、 查 ， 所 以 主体 逻辑 是 通用 的 ， 比 如 序列 化 、 反 序列 化 、 
基于 Key-Value 的 存储 ， 以 及 这 个 过 程 中 的 数据 校 验 和 权限 控制 等 问 


je 





通过 以 上 分 析 ， 我 们 发 现 这 个 系统 的 核心 对 象 只 有 两 个 : 资源 对 象 
与 操作 资源 对 象 的 Storage 服 务 。 虽 然 各 个 资源 的 Storage 服 务 的 主体 功能 
相同 ， 都 是 将 资源 存储 到 etcd 这 个 Key-Value 后 端 存储 系统 上 并 提供 相关 
操作 ， 但 不 同类 型 资源 的 Storage 服 务 的 接口 和 具体 逻辑 还 是 有 差别 的 ， 
比如 某 类 资源 是 不 允许 更 新 的 ， 有 些 资 源 则 允许 “Connect*， 所 以 这 里 
的 设计 是 Kubernetes API Server 的 最 有 代表 性 的 经 典 设 计 一 一 资源 服务 
接口 的 细 分 与 组 合 设计 。 





如 图 6.2 所 示 是 此 设计 的 全 景 图 〈 以 Pod 资 源 对 象 为 例 ) 。 资 源 服务 
接口 被 拆 分 为 rest.Create、rest.Updater、rest.CreateUpdate (2H 4 Y Create 
与 Updater 接 口 ) 、rest.GracefulDelete (支持 延迟 删除 资源 的 接口 〉、 
rest.Patcher (组 合 更 新 与 Get 接 口 )、rest.Connect (开局 HTTP 连 接 到 该 
资源 进行 操作 ， 比 如 连接 到 一 个 Pod 中 执行 某 个 bash 命 令 ) 等 10 个 细 分 
接口 。 





考虑 到 大 多 数 资 源 对 象 都 需要 基本 的 CRUD 接 口 ， 这 束 是 
rest.StandardStorage 这 个 聚合 型 “标准 存储 服务 ?接口 出 现 的 原因 。 而 作为 
StandardStorage 的 默认 实现 ，pkg/registry/generic/etcd/etcd.go 里 etcd 这 个 
对 象 实 现 了 基于 etcd 后 端 存储 的 所 有 有 具体 操作 ， 而 各 种 资源 的 Storage 服 
务 则 通过 将 请 求 代理 到 etcd 对 象 上 来 完成 具体 的 功能 。 





这 里 有 点 让 人 难以 理解 的 是 PodStorage 与 它 的 属性 Pod 的 关系 ， 其 实 
PodStorage 这 个 对 象 是 一 个 聚合 了 与 Pod 相 关 的 各 个 资源 的 存储 服务 ， 多 
A SEINE CHEZ ZINA T: 





// PodStorage includes storage for pods and all sub reso 


type PodStorage struct { 


Pod *REST 
Binding *BindingREST 
Status *StatusREST 
Log *LOQREST 
Proxy *ProxyREST 
Exec *ExecREST 


PortForward *PortForwardREST 


rest.Create rest.Updater rest.GracefulDeleter 


rest.Getter 
rest.CreateUpdate 
peel rest.Lister 


rest.StandardStorage al 
rest. Watcher 


Com) rest.Deleter rest.Patcher 
DA 


ul 


rest.Redirector rest.Connecter 





图 6.2 API Server 的 Storage 设 计 全 景 图 


所 以 ， 这 里 的 PodStorage 应 该 重合 4 为 AllPodResStorage， 而 真正 的 
PodStorage 上 就 是 里 面 的 那个 Pod 变 量 ， 这 个 变量 是 对 etcd 实 例 的 一 个 引 
用 ， 然 后 又 实现 了 rest.Redirector 接 口 。 现 在 你 终于 能 理解 PodRegistry 引 
用 Pod 变 量 而 不 是 PodStorage 来 实现 Pod 操 作 的 真正 原因 了 吧 ? 


最 后 ， 我 们 来 说 说 PodRegistry 存 在 的 目的 。 从 之 前 的 代码 分 析 来 
看 ， 一 个 来 自 外 部 的 针对 某 个 资源 的 Rest API 发 起 的 请 求 最 后 落 到 对 应 
资源 的 rest.Storage 对 象 上 ， 由 restful.RouteFunction 调 用 此 对 象 的 相关 方 
法 完成 资源 的 操作 并 生成 应 答 返 回 给 客户 端 ， 这 个 过 程 并 没有 涉及 对 应 
资源 的 Registry 服 务 。 那 么 问题 来 了 ， 资 源 的 Registry 接 口 存在 的 理由 是 
什么 呢 ? 答案 很 简单 ， 对 比 Storage 接 口 与 Registry 中 的 资源 创建 方法 的 





签名 ， 下 面 是 二 者 的 源码 对 比 ， 后 者 更 符合 手工 调用 ”: 





Storage 中 创建 通用 的 资源 对 象 的 接口 
Create(ctx api.Context, obj runtime.Object) (runtime.Obj: 
PodRegistry 中 创建 Pod 资 源 的 接口 


CreatePod(ctx api.Context, pod *api.Pod) error 





在 Kubernetes API Server 中 为 每 类 资源 都 创建 并 提供 了 一 个 Registry 
接口 服务 的 目的 是 供 内 部 模块 的 编程 使 用 ， 而 非 对 外 提供 服务 ， 很 多 文 
档 都 错误 理解 了 这 个 问题 。 


本 节 最 后 给 出 了 如 图 6.3 所 示 的 经 典 的 Kubernetes 的 Master 节 点 数据 
流 图 ， 此 刻 这 个 图 在 你 眼 里 可 能 已 经 什么 都 不 算 了 ， 因 为 你 已 经 洞 穿 了 
幕后 的 一 切 。 





Eted Registry 
Storage 


图 6.3 “Master 节点 数据 流 图 





6.3 ”kube-controller-manager 进 程 源码 分 析 


运行 在 Master 节 点 上 的 第 2 个 进程 就 是 kube-controller-manager 进 
程 ， 即 Controller Manager Server，Kubernetes 的 核心 进程 之 一 ， 其 主要 
目的 是 实现 Kubernetes 集 群 的 故障 检测 和 恢复 的 自动 化 工作 ， 比 如 内 部 
组 件 EndpointController 控 制 右 负 贡 Endpoints 对 象 的 创建 和 更 新 ; 
ReplicationManager 根 据 注 册 表 中 的 ReplicationController 的 定义 ， 完 成 
Pod 的 复制 或 者 移 除 ， 以 确保 复制 数量 的 一 致 性 ，NodeController 负 贡 
Minion 节 点 的 发 现 、 管 理 和 监控 。 





6.3.1 ”进程 启动 过 程 


kube-controller-manager 进 程 的 入 口 源 码 位 置 如 下 : 


github/com/GoogleCloudPlatform/kubernetes/cmd/kube-contr' 


入 口 main() 函数 的 逻辑 如 下 : 


func main() { 
runtime .GOMAXPROCS( runtime .NumCPU( ) ) 
s := app.NewCMServer() 
s.AddFlags(pflag.CommandLine ) 
util.InitFlags() 
util.InitLogs() 
defer util.FlushLogs() 
verflag.PrintAndExitIfRequested() 
if err := s.Run(pflag.CommandLine.Args()); err != nil 
fmt.Fprintf(os.Stderr, "%v\n", err) 


os.Exit(1) 


从 源码 可 以 看 出 ， 关 键 代码 只 有 两 行 ， 创 建 一 个 CMServer 并 调用 
Run 方 法 启动 服务 。 下 面 我 们 分 析 CMServer 这 个 结构 体 ， 它 是 Controller 
Manager Server 进 程 的 主要 上 下 文 数 据 结构 ， 存 放 一 些 关 键 参 数 ， 表 6.3 





是 对 CMServer 里 的 关键 参数 的 解释 。 
表 6.3 ”CMServer 的 重要 属性 


属 性 名 BA i a g 
ConcurrentEndpointSyncs 5 秒 并 发 执行 的 Endpoint 的 同步 任务 的 数量 








ConcurrentRCSynes 5 秒 并 发 执行 的 Replication Controller 的 同步 任务 的 数量 





NodeSyncPeriod 5 秒 从 CloudProvider 处 同步 Node 节点 的 周期 





NodeMonitorPeriod Node 节点 监控 的 周期 
ResourceQuotaSyncPeriod 对 资源 的 配额 使 用 情况 进行 同步 的 周期 




















NamespaceSyncPeriod Namespace 同步 的 周期 
PVClaimBinderSyncPeriod 对 PV 持久 存储 ) 和 PV 的 申请 进行 同步 的 周期 
PodEvictionTimeout 在 Node 失败 的 情况 下 ， 其 上 的 Pod 多 久 后 才 被 删除 

















master Kubernetes API Server 的 访问 地 址 





从 上 述 这 些 变量 来 看 ，Controller Manager Server 其 实 就 是 一 个 “ 超 
级 调度 中 心 ”， 它 负责 定期 同步 Node 节 点 状态 、 资 源 使 用 配额 信息 、 
Replication Conctroller、Namespace、Pod 的 PV 绑 定 等 信息 ， 也 包括 执行 
诸如 监控 Node 节 点 状态 、 清 除 失败 的 Pod 容 器 记录 等 一 系列 定时 任务 。 


在 controller-manager.go 里 创建 CMServer 实 例 并 把 参数 从 命令 行 中 传 
递 到 CMServer 后 ， 就 调用 它 的 func (s*CMServer) Run (_[Jstring) 方法 
进入 关键 流程 ， 这 里 首先 创建 一 个 Rest ”Client 对 象 用 于 访问 Kubernetes 
API Server 提 供 的 API 服 务 : 


kubeClient, err := client.New(kubeconfig) 
if err != nil { 


glog.Fatalf("Invalid API configuration: %v", err 


随后 ， 创 建 一 个 HITP Server 以 提供 必要 的 性 能 分 析 (Performance 
Profile) 和 性 能 指标 度量 (Metrics) 的 Rest 服 务 : 


go func() { 


}() 


mux := http.NewServeMux( ) 

healthz.InstallHandler (mux) 

if s.EnableProfiling { 
mux.HandleFunc("/debug/pprof/", pprof.Index) 
mux.HandleFunc('"/debug/pprof/profile", pprof 
mux.HandleFunc("/debug/pprof/symbol", pprof.: 

} 


mux.Handle("/metrics", prometheus.Handler()) 


server := &http.Server{ 
Addr: net.JoinHostPort(s.Address.String() 
Handler: mux, 


} 


glog.Fatal(server.ListenAndServe() ) 


我 们 注意 到 性 能 分 析 的 Rest 路 径 是 以 /debug 开 头 的 ， 表 明 是 为 了 程 
序 调试 所 用 ， 事 实 上 的 确 如 此 ， 这 里 的 几 个 Profile 选 项 都 是 针对 当前 Go 
进程 的 Profile 数 据 ， 比 如 我 们 在 Master 节 点 上 执行 curl 命 令 〈 地 址 为 
http://127.0.0.1: 10252/debug/pprof/heap) 可 以 获取 进程 的 当前 堆栈 信 
息 ， 会 输出 如 下 信息 : 





heap profile: 4: 78112 [1109: 824584] @ heap/1048576 


1: 32768 [1: 32768] @ 0x402612 Ox75ab95 0x771419 0x77137! 


1: 32768 [1: 32768] @ 0x408806 0x407968 0x97e591 O0x9895ai 


1: 12288 [1: 12288] @ 0x4199fc Ox7df75d Ox5b585c 0x5b494 


1: 288 [1: 288] @ 0x415d6a 0x43276f 0x43510f Ox42fd37 Ox. 


其 他 还 有 GC 回 收 、Symbol 查 看 、 进 程 30 秒 内 的 CPU 利用 率 、 协 程 
的 阻塞 状态 等 Profile 功 能 ， 输 出 的 数据 格式 符合 google-perftools 这 个 工 
有 具 的 要 求 ， 因 此 可 以 做 运行 期 的 可 视 化 Profile， 以 便 排 得 当前 进程 潜在 
的 问题 或 性 能 瓶 贷 。 








性 能 指标 度量 目前 主要 收集 和 统计 Kubernetes API Server 的 Rest API 
的 调用 情况 ， 执 行 curl Chttp://127.0.0.1: 10252/metrics) ， 可 以 看 到 输 
出 中 包括 大 量 类 似 下 面 的 内 容 : 


rest_client_request_latency_microseconds{url="http://cen 
rest_client_request_latency_microseconds{url="http://cen 


rest_client_request_latency_microseconds{url="http://cen 


这 些 指标 有 助 于 协助 发 现 Controller Manager Server 在 调度 方面 的 性 
能 瓶 贷 ， 因 此 可 以 理解 为 什么 会 被 包括 到 进程 代码 中 去 。 





接 下 来 ， 启 动 流 程 进入 到 关键 代码 部 分 。 在 这 里 ， 启 动 进程 分 别 创 
建 如 下 控制 器 ， 这 些 控 制 器 的 主要 目的 是 实现 资源 在 Kubernetes API 
Server 的 注册 表 中 的 周期 性 同步 工作 : 





e EndointController 负 责 对 注册 表 中 的 Kubernetes Service 的 Endpoints 信 

恩 的 同步 工作 ; 

ReplicationManager 根 据 注册 表 中 对 ReplicationController 的 定义 ， 完 

成 Pod 的 复制 或 者 移 除 ， 以 确保 复制 数量 的 一 致 性 ; 

e NodeController 则 通过 CloudProvider 的 接口 完成 Node 实 例 的 同步 工 
VE; 





e servicecontroller 通 过 CloudProvider 的 接口 完成 云 平 台中 的 服务 的 同 
步 工 作 ， 这 些 服务 目前 主要 是 外 部 的 负载 均衡 服务 ; 
e ResourceQuotaManager 负 责 资源 配额 使 用 情况 的 同步 工作 ; 


e NamespaceManager 负 责 Namespace 的 同步 工作 ; 








e PersistentVolumeClaimBinder 与 PersistentVolumeRecycler 分 别 完 成 
PersistentVolume 的 绑 定 和 回收 工作 ; 
e TokensController、ServiceAccountsController 分 别 完 成 Kubernetes 服 


务 的 Token、Account 的 同步 工作 。 


创建 并 局 动 完成 上 述 的 控制 右 以 后 ， 各 个 控制 器 就 开始 独立 工作 ， 


Controller Manager Server 启 动 完毕 。 


6.3.2 ”关键 代码 分 析 


在 6.3.1 节 对 kube-controller-manager 进 程 的 启动 过 程 进 行 了 详细 分 
析 ， 我 们 发 现 这 个 进程 的 主要 人 逻辑 就 是 启动 一 系列 的 “控制 器 ”*"。 这 里 以 
Kubernetes 里 比较 关键 的 Pod 副 本 (Pod Replica) 数量 的 控制 实现 过 程 为 
例 ， 来 分 析 完 成 这 个 任务 的 “控制 嚣 * 一 ReplicationManager 具 体 是 如 何 
THEN. 








首先 ， 我 们 来 看 看 ReplicationManager 结 构 体 的 定义 : 


type ReplicationManager struct { 
kubeClient client.Interface 


podControl PodControlinterface 


// An rc is temporarily suspended after creating/deli 
// It resumes normal action after observing the watc 
burstReplicas int 

// To allow injection of syncReplicationController fi 


syncHandler func(rcKey string) error 
// podStoreSynced returns true if the pod store has 
// Added as a member to the struct to allow injectio 


podStoreSynced func() bool 


// A TTLCache of pod creates/deletes each rc expects 


expectations RCExpectationsManager 

// A store of controllers, populated by the rcContro. 
controllerStore cache.StoreToControllerLister 

// A store of pods, populated by the podController 
podStore cache.StoreToPodLister 

// Watches changes to all replication controllers 
rcController *framework.Controller 

// Watches changes to all pods 

podController *framework.Controller 

// Controllers that need to be updated 


queue *workqueue. Type 


在 上 述 结构 体 里 ， 比 较 关 键 的 儿 个 属性 如 下 。 


kubeClient: 用 来 访问 KubernetesAPIServer 的 Rest 客 户 端 ， 这 里 用 来 

访问 注册 表 中 定义 的 ReplicationController 对 象 并 操作 Pod。 

podControl: 实现 了 Pod 副 本 创建 的 函数 ， 其 实现 类 为 

RealPodControl (MLF 

kubernetes/pkg/controller/controller_utils.go) 。 

syncHandler: 是 RC (ReplicationController) 的 同步 实现 方法 ， 完 成 
具体 的 RC 同步 逻辑 (创建 Pod 副 本 时 调用 PodControl 的 相关 方 

法 ) ， 在 代码 中 其 被 赋值 为 

ReplicationManager.syncReplicationController 方 法 。 

expectations: 是 Pod 副 本 在 创建 、 删 除 过 程 中 的 流 控 机 制 的 重要 组 

成 部 分 。 

controllerStore: 是 一 个 具备 本 地 绥 存 功能 的 通用 的 资源 存储 服务 ， 


这 里 存放 framework.Controller 运 行 过 程 中 从 Kubernetes API Server 同 
步 过 来 的 资源 数据 ， 目 的 是 减轻 资源 同步 过 程 中 对 Kubernetes API 
Server 造 成 的 访问 压力 并 提高 资源 同步 的 效率 。 

rcController: framework.Controller 的 一 个 实例 ， 用 来 实现 RC 同 步 的 
任务 调度 逻辑 。 

framework.Controller: 是 kube-controller-manager 里 设计 的 用 于 资源 
对 象 同步 逻辑 的 专用 任务 调度 框架 。 

podStore: 类 似 于 controllerStore 的 作用 ， 用 来 存 取 和 获取 Pod 资 源 对 
象 。 

podController: 类 似 于 rcController 的 作用 ， 用 来 实现 Pod 同 步 的 任务 
调度 逻辑 。 





理解 了 ReplicationManager 结 构 体 的 重要 参数 及 其 作用 之 后 ， 我 们 来 


看 controller.NewReplicationManager (kubeClient client.Interface, 
burstReplicas int) *ReplicationManager 这 个 构造 函数 中 的 关键 代码 ， 注 
意 到 这 里 通过 调用 framework.NewInformer () 方法 先后 创建 了 用 于 RC 
同步 及 Pod 同 步 的 framework.Controller。 下 面 是 

framework.NewInformer () 方法 的 源码 : 


func NewInformer ( 
lw cache.ListerWatcher, 
objType runtime.Object, 
resyncPeriod time.Duration, 
h ResourceEventHandler, 
) (cache.Store, *Controller) { 
clientState := cache.NewStore(DeletionHandlingMetaNa 


fifo := cache.NewDeltaFIFO(cache.MetaNamespaceKeyFun 


cfg := &Config{ 


Queue: fifo, 
ListerWatcher: lw, 
ObjectType: objType, 


FullResyncPeriod: resyncPeriod, 
RetryOnError: false, 
Process: func(obj interface{}) error { 
// from oldest to newest 
for _, d := range obj.(cache.Deltas) { 
switch d.Type { 
case cache.Sync, cache.Added, cache.Upda 
if old, exists, err := clientState.G 
if err := clientState.Update(d.0 


return err 


} 
h.OnUpdate(old, d.Object) 
} else { 


if err := clientState.Add(d.Obje 
return err 

} 
h.OnAdd(d.Object) 

} 

case cache.Deleted: 

if err := clientState.Delete(d.Objec 

return err 


} 
h.OnDelete(d.Object) 


} 
return nil 
上 
} 


return clientState, New(cfg) 


在 上 述 代 码 中 ，lw (ListerWatcher) 用 来 获取 和 监测 资源 对 象 的 变 
化 ， 而 fifo 则 是 一 个 DeltaFIFO 的 Queue， 用 来 存放 变化 的 资源 (需要 同 
步 的 资源 ) 。 当 Controller 框 架 发 现 有 变化 的 资源 需要 处 理 时 ， 就 会 将 新 
资源 与 本 地 绥 存 clientState 中 的 资源 进行 对 比 ， 然 后 调用 相应 的 资源 处 
理 函 数 ResourceEventHandler 的 方法 ， 完 成 具体 的 处 理 逻 辑 。 下 面 是 针 
对 RC 的 ResourceEventHandler 的 具体 实现 : 


framework.ResourceEventHandlerFuncs{ 

AddFunc: rm.enqueueController, 

UpdateFunc: func(old, cur interface{}) { 
oldRC := old. (*api.ReplicationController 
curRC := cur.(*api.ReplicationController 
if oldRC.Status.Replicas != curRC.Status 

glog.V(4).Infof("Observed updated re 
} 


rm.enqueueController (cur ) 


ty 


DeleteFunc: rm.enqueueController, 


在 上 述 源码 中 ， 我 们 看 到 当 RC 里 Pod 的 副本 数量 属性 发 生变 化 以 
后 ，ResourceEventHandler 束 将 此 RC 放 入 ReplicationManager 的 queue 队 列 
中 等 待 处 理 ， 为 什么 没有 在 这 个 handler 函 数 中 直接 处 理 而 是 先 放 入 队列 
再 异步 处 理 呢 ? 最 主要 的 一 个 原因 是 Pod 副 本 创建 的 过 程 比较 耗 时 。 
Controller 框 架 把 需要 同步 的 RC 对 象 放 入 queue 以 后 ， 接 下 来 是 谁 在 “ 消 
费 ” 这 个 队列 呢 ? 答案 就 在 ReplicationManager 的 Run O 方法 中 : 











func (rm *ReplicationManager) Run(workers int, stopCh <- 
defer util.HandleCrash() 
go rm.rcController.Run(stopCh) 
go rm.podController.Run(stopCh) 
for i := 0; i < workers; i++ { 
go util.Until(rm.worker, time.Second, stopCh) 
} 
<-stopch 
glog.Infof("Shutting down RC Manager") 


rm.queue.ShutDown() 


上 述 代码 首先 启动 rcController 与 podController 这 两 个 Controller， 启 
动 之 后 ， 这 两 个 Controller 就 分 别 开 始 拉 取 RC 与 Pod 的 变动 信息 ， 随 后 义 
启动 N 个 协 程 并 发 处 理 RC 的 队列 ， 其 中 func Until (f func © , period 
time.Duration，stopCh<-chan  struct{}) 方法 的 逻辑 是 按照 指定 的 周期 
period 执 行 方法 f。 下 面 是 ReplicationManager 的 worker 方 法 的 源码 ， 负 责 
从 RC 队列 中 拉 取 RC 并 调用 rm 的 syncHandler 方 法 完成 具体 处 理 : 


func (rm *ReplicationManager) worker() { 


for { 
func() { 
key, quit := rm.queue.Get() 
if quit { 
return 
} 
defer rm.queue.Done(key) 
err := rm.syncHandler (key. (string) ) 
if err != nil { 


glog.Errorf("Error syncing replication c 


}() 


从 ReplicationManager 的 构造 函数 中 我 们 得 知 : syncHandler 在 这 里 
其 实 是 func (rm*ReplicationManager) syncReplicationController (key 


string) 方法 。 下 面 是 该 方法 的 源码 : 


func (rm *ReplicationManager) syncReplicationController ( 
startTime := time.Now() 
defer func() { 


glog.V(4).Infof("Finished syncing controller %q 
}() 


obj, exists, err := rm.controllerStore.Store.GetByKe' 


if !exists { 


glog.Infof("Replication Controller has been dele 
rm.expectations.DeleteExpectations(key) 


return nil 


} 

if err != nil { 
glog.Infof("Unable to retrieve rc %v from store: 
rm.queue.Add(key ) 
return err 

} 

controller := *obj.(*api.ReplicationController ) 


if !rm.podStoreSynced() { 
// Sleep so we give the pod reflector goroutine 
time .Sleep(PodStoreSyncedPollPeriod) 
glog.Infof("Waiting for pods controller to sync, 
rm.enqueueController(&controller ) 


return nil 


} 
rcNeedsSync := rm.expectations.SatisfiedExpectations 
podList, err := rm.podStore.Pods(controller .Namespac 
if err != nil { 
glog.Errorf("Error getting pods for rc %q: %v", 
rm. queue.Add( key ) 
return err 
} 


filteredPods := filterActivePods(podList.Items) 


if rcNeedsSync { 
rm.manageReplicas(filteredPods, &controller ) 


if err := updateReplicaCount(rm.kubeClient.Replicatio 
rm.enqueueController(&controller ) 


} 


return nil 


在 上 述 代 人 码 里 有 一 个 重要 的 流 控 变量 rceNeedsSync。 为 了 限 流 ， 在 
RC 同步 逻辑 的 过 程 中 ， 一 个 RC 每 次 最 多 执行 N 个 Pod 的 创建 、 删 除 ， 如 
果 某 个 RC 的 同步 过 程 涉 及 的 Pod 副 本 数量 超过 burstReplicas 这 个 赋值 ， 
束 会 采用 RCExpectations 机 市 进行 限 流 。RCExpectations 对 象 可 以 理解 为 
一 个 简单 的 规则 : 即 在 限定 的 时 间 内 执行 N 次 操作 ， 每 次 操作 都 使 计数 
器 减 一 ， 计 数 器 为 零 表 示 N 个 操作 已 经 完成 ， 可 以 进行 下 一 批 次 的 操作 
Ts 


Kubernetes 为 什么 会 设计 这 样 一 个 流程 控制 机 制 ? 其 实 答案 很 简单 
一 一 为 了 公平 。 因 为 谷歌 的 开发 Kubernetes 的 资深 大 牛 们 早已 预见 到 某 
个 RC 的 Pod 副 本 一 次 扩容 至 100 倍 的 极端 情况 可 能 真实 发 生 ， 如 果 没 有 
流 控 机 制 ， 则 这 个 巨 无 名 的 RC 同步 操作 会 导致 其 他 众多 “散户 ” 崩 演 ! 
这 绝对 不 是 谷歌 的 理念 。 





接着 看 上 述 代码 里 所 调用 的 ReplicationManager 的 manageReplicas 方 
法 ， 这 是 RC 同步 的 具体 逻辑 实现 ， 此 方法 采用 了 并 发 调用 的 方式 执行 
批量 的 Pod 副 本 操作 任务 ， 相 关 代 码 如 下 : 


wait := sync.WaitGroup{} 
wait .Add(diff) 
glog.V(2).Infof("Too few %q/%q replicas, need %d 
for i := 0; i < diff; i++ { 
go func() { 
defer wait.Done() 
if err := rm.podControl.createReplica(co 
glog.V(2).Infof("Failed creation, decremen 
rm.expectations.CreationObserved(con 


util.HandleError(err ) 


}() 
} 
wait ,Wait( ) 


妃 踪 人 至此， 我 们 才 看 到 创建 Pod 副 本 的 真正 代码 在 
PodControl.createReplica () 方法 里 ， 而 此 方法 的 具体 实现 方法 则 是 
RealPodControl.createReplica () ， 位 于 controller_utils.go 里 。 通 过 分 析 
该 方法 ， 我 们 可 以 知道 创建 Pod 副 本 的 过 程 就 是 创建 一 个 Pod 资 源 对 象 ， 
并 把 RC 中 定义 的 Pod 模 板 赋 值 给 该 Pod 对 象 ， 并 且 Pod 的 名 字 用 RC 的 名 
字 做 前 级 ， 最 后 调用 Kubernetes ”Client 将 Pod 对 象 通 过 Kubernetes API 
Server 写 入 后 端的 etcd 存 储 中 。 


在 本 节 最 后 ， 我 们 来 分 析 一 下 Controller 框 架 中 如 何 实 现 资源 对 象 的 
查询 和 监听 逻辑 并 且 在 资源 发 生变 动 时 回调 Controller.Config 对 象 中 的 
Process 方 法 : func (obj interface{}) ， 最 终 完 成 整个 Controller 框 架 的 闭 


自 先 ， 在 Controller 框 架 中 构建 了 Reflector 对 象 以 实现 资源 对 象 的 查 
询 和 监听 逻辑 ， 它 的 源码 位 于 pkg/client/cache/reflector.go 中 ， 我 们 看 一 
下 这 个 对 象 的 数据 结构 就 基本 明白 了 其 工作 原理 : 





// Reflector watches a specified resource and causes all 
type Reflector struct { 
// The type of object we expect to place in the stor 
expectedType reflect.Type 
// The destination to sync up with the watch source 
store Store 
// listerWatcher is used to perform lists and watche 
listerWatcher ListerWatcher 
// period controls timing between one watch ending a 
// the beginning of the next one. 
period time .Duration 
resyncPeriod time.Duration 
// lastSyncResourceVersion is the resource version ti 
// observed when doing a sync with the underlying st 
// it is thread safe, but not synchronized with the 
lastSyncResourceVersion string 
// lastSyncResourceVersionMutex guards read/write ac 


lastSyncResourceVersionMutex sync.RwWMutex 


核心 思路 就 是 通过 listerWatcher 去 获取 资源 列表 并 监听 资源 的 变 
化 ， 然 后 存储 到 store 中 。 这 里 你 可 能 有 个 疑问 ， 这 个 store 完 竟 是 哪个 对 
象 ? 是 ReplicationManager 里 的 controllerStore 还 是 


framework.NewInformer () 方法 里 创建 的 fifo 队 列 ? 


下 面 的 两 段 来 自 pkg/controller/framework/controller.go 的 代码 会 告诉 
我 们 答案 。 


首先 是 来 自 Controller 的 run 方 法 func (c*Controller) Run (stopCh<- 
chan struct{}) 的 代码 片段 : 


r := cache.NewReflector ( 
c.config.ListerWatcher, 
c.config.ObjectType, 
c.config.Queue, 


c.config.FullResyncPeriod, 


然后 是 来 自 Controller 的 NewInformer 方 法 func NewInformer (lw 
cache.ListerWatcher, objType runtime.Object, resyncPeriod 


time.Duration, h ResourceEventHandler, ) (cache.Store, *Controller) 


中 的 代码 片段 : 


cfg := &Config{ 


Queue: fifo, 
ListerWatcher: lw, 
ObjectType: objType, 


FullResyncPeriod: resyncPeriod, 


RetryOnError: false, 


分 析 上 述 代 码 ， 我 们 发 现 Reflector 中 的 store 其 实 是 引用 


Controller.Config 里 的 Queue 属 性 ， 即 fifo 队 列 ， 而 非 ReplicationManager 
里 的 controllerStore。 我 们 费 了 这 么 大 的 劲 ， 才 弄 明白 这 个 简单 的 问题 ， 
这 告诉 我 们 一 个 事实 : 编程 中 有 良好 的 命名 规则 很 重要 。 


下 面 这 段 代 码 是 Controller 从 队列 Queue 中 拉 取 资源 对 象 并 且 交 给 
Controller.Config 对 象 中 的 Process 方 法 func (obj interface{}) 进行 处 理 ， 
从 而 最 终 完 成 了 整个 Controller 框 架 的 闭环 过 程 。 


func (c *Controller) processLoop() { 


for { 
obj := c.config.Queue.Pop( ) 
err := c.config.Process(obj ) 
if err != nil { 
if c.config.RetryOnError { 
// This is the safe way to re-enqueue. 
c.config.Queue.AddIfNotPresent (obj) 
} 
} 
} 


至 于 上 述 过 程 的 调用 则 是 在 Controller 启 动 (Run 方 法 ) 的 最 后 一 步 
里 ，Controller 框 架 定时 每 秒 调 用 一 次 上 述 函 数 ， 代 人 码 如 下 : 


util.Until(c.processLoop, time.Second, stopCh) 


最 后 ， 给 读者 留 一 个 源码 解读 的 问题 ， 即 ReplicationManager 里 除了 


RC Controller， 又 构造 了 一 个 用 于 Pod 的 Controller， 它 的 逻辑 具体 是 怎 
样 实现 的 ? 它 与 RC Controller 是 怎样 交互 的 ? 


6.3.3 Wiese 


相对 于 之 前 的 Kubernetes API Server 设 计 来 说 ，Kubernetes Controller 
Server 的 设计 没有 那么 复杂 ， 而 且 精 彩 依旧 。 不 愧 是 大 师 的 作品 ， 
ControllerFramework 精 巧 细致 的 设计 使 得 整个 进程 中 各 种 资源 对 象 的 同 
步 逻 辑 在 代码 实现 方面 保持 了 高 度 一 致 性 与 简捷 性 。 此 外 ， 在 关键 资源 
RC (ReplicationController) 的 同步 逻辑 中 所 采用 的 流 控 机 制 也 简单 、 高 
效 。 





本 节 我 们 针对 Kubernetes Controller ”Server 中 的 精华 部 分 一 一 
Controller Framework 的 设计 做 一 个 整理 分 析 。 首 先 ， 
framework.Controller 内 部 维护 一 个 Config 对 象 ， 保 留 了 一 个 标准 的 消 
恩 、 事 件 分 发 系统 的 三 要 素 。 


e 生产 者 : cache.ListerWatch. 
e 队列 :， cache.cacheStore (Queue) 。 
。 消费 者 : 用 回调 函数 来 模拟 


(framework.ResourcceEventHandlerFuncs) 。 


由 于 生产 者 的 逻辑 比较 复杂 ， 在 这 个 系统 中 也 有 其 特殊 性 ， 即 拉 取 
资源 并 监控 资源 的 变化 ， 由 此 产生 了 真正 的 待 处 理 任务 ， 所 以 又 设计 了 
一 个 ListerWatcher 接 口 ， 将 底层 的 复杂 逻辑 “框架 化 ”， 放 入 
cache.Reflector 中 ， 使 用 者 只 要 简单 地 实现 ListerWatcher 接 口 的 ListFunc 
与 WatchFunc 即 可 。 另 外 ，cache.Reflector 也 是 独立 于 Controller 
Framework 的 一 个 组 件 ， 隶 属于 cache 包 ， 它 的 功能 是 将 任意 资源 对 象 拉 





取 到 本 地 缓存 中 并 监控 资源 的 变化 ， 保 持 本 地 缓存 的 同步 ， 其 目标 是 减 
轻 对 Kubernetes API Server 的 请 求 压 力 。 


图 6.4 给 出 了 ControllerFramework 的 整体 架构 设计 图 。 


通过 Kubemetes Rest Client 拉 取 并 监控 
资源 的 变化 ， 己 发 生 改 变 的 资源 放 入 
FIFO 队列 中 等 待 处 理 






Kubemetes 
cacheReflector 用 二 = 一 œ cache.ListerWatcher 4 eee 
A | / 

创建 Refelctor 并 周期 性 调用 | [se 

ListAndWatch 方法 | cient client 
framework.Controller Ý 

cache. Store 
周期 性 调用 Handler 





方法 处 理 队列 


framework ResourceEventHandlerFuncs 


图 6.4 Controller Framework 的 整体 架构 设计 图 


Kubernetes Controller Server 中 所 有 涉及 同步 的 资源 都 采用 了 
Controller Framework 框 架 来 进行 驱动 ， 图 6.5 给 出 了 整体 设计 示意 图 。 


从 图 6.5 可 以 看 出 ， 除 了 Node、Route、CloudService 这 三 个 资源 依 
赖 于 Kubernetes 所 处 的 云 计算 环境 ， 只 能 通过 CloudProvider 接 口 所 提供 
的 API 来 完成 资源 同步 ， 其 他 资源 都 采用 了 Controller Framework 框 架 来 
进行 资源 同步 。 图 中 的 虚线 第 头 表 示 针 对 目标 资源 创建 了 一 个 
framework.Controller 对 象 ， 其 中 的 某 些 资源 如 RC、PV、Tokens 的 同步 
过 程 需要 获取 并 监听 其 他 与 之 相关 联 的 资源 对 象 。 这 里 只 有 
ResourceQuota 资 源 比 较 另 类 ， 它 没有 采用 Controller Framework， 一 个 原 


因 是 ResourceQuota 涉 及 很 多 资源 对 象 ， 不 大 好 应 用 
framework.Controller， 另 外 一 个 原因 可 能 是 写 ResourceQuotaManager 的 
大 牛 拥 有 比较 浪漫 的 情怀 ， 看 看 下 面 这 段 Kubernetes 中 最 优美 的 代码 
NE: 





func (rm *ResourceQuotaManager ) Run(period time.Duration 
rm.syncTime = time.Tick(period) 


go util.Forever(func() { rm.synchronize() }, period) 


核心 代码 翻译 过 来 就 是 这 个 意思 : ete EY See Ee, — 
EDER I! 























图 6.5 Kubernetes Controller Server 整 体 设计 示意 图 


6.4 kube-scheduler 进 程 源码 分 析 


Kubernetes Scheduler Server 是 由 kube-scheduler 进 程 实现 的 ， 它 运行 
在 Kubernetes 的 管理 节点 一 -Master 上 并 主要 负责 完成 从 Pod 到 Node 的 调 
度 过 程 。Kubernetes Scheduler Server 跟 踪 Kubernetes 集 群 中 所 有 Node 的 
资源 利用 情况 ， 并 采取 合适 的 调度 策略 ， 确 保 调 度 的 均 衔 性 ， 避 免 集群 
中 的 某 些 节点 “过 载 ?。 从 某 种 意义 上 来 说 ，Kubernetes Scheduler Server 
也 是 Kubernetes 集 群 的 “大 脑 ”。 











谷歌 作为 公有 云 的 重要 供应 商 ， 积 累 了 很 多 经 验 并 且 了 解 客户 的 需 
求 。 在 谷歌 看 来 ， 客 户 并 不 真正 关心 他 们 的 服务 究竟 运行 在 哪 台 机 器 
上 ， 他 们 最 关心 服务 的 可 靠 性 ， 和 希望 发 生 故 障 后 能 自动 恢复 。 遵 循 这 一 
指导 思想 ，Kubernetes Scheduler Server 实 现 了 “完全 市 场 经 济 ” 的 调度 原 
则 并 彻底 抛弃 了 传统 意义 上 的 “计划 经 济 ”。 


下 面 我 们 分 别 对 其 启动 过 程 、 关 键 代码 分 析 及 设计 总 结 等 方面 进行 
深入 分 析 和 讲解 。 


6.4.1 ”进程 启动 过 程 


kube-scheduler 进 程 的 入 口 类 源码 位 置 如 下 : 


github/com/GoogleCloudPlatform/kubernetes/plugin/cmd/kub: 


入 口 main ©) 函数 的 逻辑 如 下 : 


func main() { 
runtime .GOMAXPROCS( runtime .NumCPU( ) ) 
s := app.NewSchedulerServer () 
s.AddFlags(pflag.CommandLine ) 
util.InitFlags() 
util.InitLogs() 
defer util.FlushLogs() 
verflag.PrintAndExitIfRequested() 


s.Run(pflag.CommandLine.Args() ) 


对 上 述 代 码 的 风格 和 人 逻辑 我 们 再 熟悉 不 过 了 : 创建 一 个 
SchedulerServer 对 象 ， 将 命令 行 参数 传 入 ， 并 且 进 入 SchedulerServer 的 
Run 方 法 ， 无 限 循环 下 去 。 


按照 惯例 ， 我 们 首先 看 看 SchedulerServer 的 数据 结构 
(app/server.go) ， 下 面 是 其 定义 : 


type SchedulerServer struct { 
Port int 
Address util.IP 
AlgorithmProvider string 
PolicyConfigFile string 
EnableProfiling bool 
Master string 


Kubeconfig string 








这 里 的 关键 属性 有 以 下 两 个 。 


e AlgorithmProvider: 对 应 参数 algorithm-provider， 是 
AlgorithmProviderConfig 的 名 称 。 
e PolicyConfigFile: 用 来 加 载 调度 策略 文件 。 


从 代码 上 来 看 这 两 个 参数 的 作用 其 实 是 一 样 的 ， 都 是 加 载 一 组 调度 
规则 ， 这 组 调度 规则 要 么 在 程序 里 定义 为 一 个 
AlgorithmProviderConfig， 要 么 保存 到 文件 中 。 下 面 的 源码 清楚 地 解释 
了 这 个 过 程 : 


func (s *SchedulerServer) createConfig(configFactory *fa 
var policy schedulerapi.Policy 


var configData []byte 


if _, err := os.Stat(s.PolicyConfigFile); err == nil 


configData, err = ioutil.ReadFile(s.PolicyConfig 


if err != nil { 

return nil, fmt.Errorf("Unable to read polic' 
} 
err = latestschedulerapi.Codec.DecodeInto(config 
if err != nil { 


return nil, fmt.Errorf("Invalid configuratio 


return configFactory.CreateFromConfig(policy ) 


// if the config file isn't provided, use the specif: 
// check of algorithm provider is registered and fai. 
_, err := factory.GetAlgorithmProvider(s.AlgorithmPri 
if err != nil { 


return nil, err 


return configFactory.CreateFromProvider(s.AlgorithmP 


创建 了 SchedulerServer 绪 构 体 实例 后 ， 调 用 此 实例 的 方法 
func (s*APIServer) Run (_[]string) ， 进 入 关键 流程 。 首 先 ， 创 建 一 个 
Rest Client 对 象 用 于 访问 Kubernetes API Server 提 供 的 API 服 务 : 


kubeClient, err := client.New(kubeconfig) 


if err != nil { 


glog.Fatalf("Invalid API configuration: %v", err 


随后 ， 创 建 一 个 HITP Server 以 提供 必要 的 性 能 分 析 (Performance 
Profile) 和 性 能 指标 度量 (Metrics) 的 Rest 服 务 : 


go func() { 

mux := http.NewServeMux( ) 

healthz.InstallHandler (mux) 

if s.EnableProfiling { 
mux.HandleFunc("/debug/pprof/", pprof.Index) 
mux.HandleFunc("/debug/pprof/profile", pprof 
mux.HandleFunc("/debug/pprof/symbol", pprof.: 

} 


mux.Handle("/metrics", prometheus.Handler()) 


server := &http.Servert{ 
Addr: net.JoinHostPort(s.Address.String() 
Handler: mux, 

} 


glog.Fatal(server.ListenAndServe() ) 


}() 





接 下 来 ， 启 动 程序 构造 了 ConfigFactory， 这 个 结构 体 包 括 了 创建 一 
个 Scheduler 所 需 的 必要 属性 。 


e PodQueue: 需要 调度 的 Pod 队 列 。 


e BindPodsRateLimiter: 调度 过 程 中 限制 Pod 绑 定 速 度 的 限 速 器 。 

e modeler: 这 是 用 于 优化 Pod 调 度 过 程 而 设计 的 一 个 特殊 对 象 ， 用 

于 “预测 未 来 "。 一 个 Pod 被 计划 调度 到 机 器 A 的 事实 被 称 为 assumed 

调度 ， 即 假定 调度 ， 这 些 调度 安排 被 保存 到 特定 队列 里 ， 此 时 调度 

过 程 是 能 看 到 这 个 预 安排 的 ， 因 而 会 影响 到 其 他 Pod 的 调度 。 

PodLister: 负 贡 拉 取 已 经 调度 过 的 ， 以 及 被 假定 调度 过 的 Pod 列 

FR o 

e NodeLister: 负责 拉 取 Node 节 点 (Minion) 列表 。 

e ServiceLister: 负责 拉 取 Kubernetes 服 务 列表 。 

e ScheduledPodLister、scheduledPodPopulator: Controller 框 架 创 建 过 
程 中 返回 的 Store 对 象 与 controller 对 象 ， 负 责 定 期 从 Kubernetes API 
Server 上 拉 取 已 经 调度 好 的 Pod 列 表 ， 并 将 这 些 Pod 从 modeler 的 假定 
调度 过 的 队列 中 删除 。 


在 构造 ConfigFactory 的 方法 factory.NewConfigFactory (kubeClient ) 
中 ， 我 们 看 到 下 面 这 段 代 码 : 


c.ScheduledPodLister.Store, c.scheduledPodPopulator = fri 
c.createAssignedPodLw(), 
&api.Pod{}, 
0, 
framework.ResourceEventHandlerFuncs{ 
AddFunc: func(obj interface{}) { 
if pod, ok := obj.(*api.Pod); ok { 
c.modeler.LockedAction(func() { 
c.modeler .ForgetPod(pod) 
}) 


ty 
DeleteFunc: func(obj interface{}) { 
c.modeler.LockedAction(func() { 
switch t := obj.(type) { 
case *api.Pod: 
c.modeler .ForgetPod(t) 
case cache.DeletedFinalStateUnknown: 


c.modeler .ForgetPodByKey(t.Key ) 


t) 
ty 
ty 


这 里 沿用 了 之 前 看 到 的 controller framework) 4, _Ei&Controller 
实例 所 做 的 事情 是 获取 并 监听 已 经 调度 的 Pod 列 表 ， 并 将 这 些 Pod 列 表 从 
modeler 中 的 “assumed” 队 列 中 删除 。 





接 下 来 ， 局 动 进程 用 上 述 创建 好 的 ConfigFactory 对 象 作 为 参数 来 调 
用 SchdulerServer 的 createConfig 方 法 ， 创 建 一 个 Scheduler.Config 对 象 ， 
而 此 段 a 的 关键 逻辑 则 集中 在 ConfigFactory 的 CreateFromKeys 这 个 函 
数 里 ， 其 主要 步 又 如 下 。 


(1) 创建 一 个 与 Pod 相 关 的 Reflector 对 象 并 定期 执行 ， 该 Reflector 
负责 查询 并 监测 等 待 调度 的 Pod 列 表 ， 即 还 没有 分 配 主 机 的 
Pod (Unsigned Pod) ， 然 后 把 它们 放 入 ConfigFactory 的 PodQueue 中 等 待 


调度 o 相 天 代码 为 : 
cache.NewReflector (f.createUnassignedPodLW () , &api.Pod{}, 
f.PodQueue, 0) .RunUntil (f.StopEverything) 。 


(2) 启动 ConfigFactory 的 scheduledPodPopulator Controller 对 象 ， 
贡 定 期 从 Kubernetes API Server 上 拉 取 已 经 调度 好 的 Pod 列 表 ， 并 将 这 些 
Pod 从 modeler 中 的 假定 Cassumed) 调度 过 的 队列 中 删除 。 相 关 代码 
JJ: go f.scheduledPodPopulator.Run (f.StopEverything) 。 


(3) 创建 一 个 Node 相 关 的 Reflector 对 象 并 定期 执行 ， 该 Reflector 负 
责 查 询 并 监测 可 用 的 Node 列 表 ( 可 用 意味 着 Node 的 spec.unschedulable 属 
性 为 false) ， 这 些 Node 被 放 入 ConfigFactory 的 NodeLister.Store 里 。 相 关 
代码 为 : cache.NewReflector (f.createMinionLW () , &api.Node{}, 
f.NodeLister.Store, 0) .RunUntil (f.StopEverything) 。 





(4) 创建 一 个 Service 相 关 的 Reflector 对 象 并 定期 执行 ， 该 Reflector 
负责 查询 并 监测 已 定 x 的 Service 列 表 ， 并 放 入 ConfigFactory 的 
ServiceLister.Store 里 。 这 个 过 程 的 目的 是 Scheduler 需 要 知道 一 个 Service 
当前 所 创建 的 所 有 Pod， 以 便 能 正确 地 进行 调度 。 相 关 代 人 码 为 : 
cache.NewReflector (f.createServiceLW () , &api.Service{}, 
f.ServiceLister.Store, 0) .RunUntil (f.StopEverything) 。 


(5) 创建 一 个 实现 了 algorithm.ScheduleAlgorithm 接 口 的 对 象 
genericScheduler， 它 负责 完成 从 Pod 到 Node 的 具体 调度 工作 ， 调 度 完 成 
的 Pod 放 入 ConfigFactory 的 PodLister 里 。 相 关 代码 为 algo: 
=scheduler.NewGenericScheduler (predicateFuncs, priorityConfigs, 


f.PodLister, r) 。 





(6) 最 后 一 步 ， 使 用 之 前 的 这 些 信息 创建 Scheduler.Config 对 象 并 
返回 。 

从 上 面 的 分 析 我 们 看 出 ， 其 实在 创建 Scheduler.Config 的 过 程 中 已 经 
完成 了 Kubernetes Scheduler Server 进 程 中 的 很 多 启动 工作 ， 于 是 整个 进 
程 的 启动 过 程 的 最 后 一 步 简单 明了 : 使 用 刚刚 创建 好 的 Config 对 象 来 构 
造 一 个 Scheduler 对 象 并 启动 运行 。 即 下 面 的 两 行 代码 : 








sched := scheduler.New(config) 


sched. Run() 





而 Scheduler 的 Run 方 法 就 是 不 停 地 执行 ScheduleOne 方 法 : 


go util.Until(s.scheduleOne, ©, s.config.StopEverything) 


scheduleOne 方 法 的 逻辑 也 比较 清晰 ， 即 获取 下 一 个 竺 调度 的 Pod,， 
然后 交 给 genericScheduler 进 行 调度 《完成 Pod 到 某 个 Node 的 绑 定 过 
RE) ， 调 度 成 功 以 后 通知 Modeler。 这 个 过 程 同 时 增加 了 限 流 和 性 能 指 


标的 逻辑 。 








6.4.2 ”关键 代码 分 析 





在 6.4.1 节 对 kube-scheduler 进 程 的 局 动 过 程 进行 详细 分 析 后 ， 我 们 大 
致 明白 了 Kubernetes Scheduler Server 的 工作 流程 ， 但 由 于 代码 中 涉及 多 
个 Pod 队 列 和 Pod 状 态 切 换 逻 辑 ， 因 此 这 里 有 必要 对 这 个 问题 进行 详细 分 
析 ， 以 和 弄 清 在 整个 调度 过 程 中 Pod 的 “来 龙 去 脉 ”。 首 先 ， 我 们 知道 
ConfigFactory 里 的 PodQueue 是 “ 竺 调度 的 Pod 队 列 ”， 这 个 过 程 是 通过 无 
限 循环 执行 一 个 Reflector 来 从 Kubernetes API Server 上 获取 待 调度 的 Pod 
列表 并 填充 到 队列 中 实现 的 ， 因 为 Reflector 框 架 已 经 实现 了 通用 的 代 
码 ， 所 以 到 了 Kubernetes Scheduler Server 这 里 ， 通 过 一 行 代码 就 能 完成 
这 个 复杂 的 过 程 : 











cache.NewReflector(f.createUnassignedPodLW(), &api.Pod{} 


上 述 代 码 中 的 createUnassignedPodLW 是 查询 和 监测 spec.nodeName 
为 空 的 Pod 列 表 ， 此 外 ， 我 们 注意 到 scheduler.Config 里 提供 了 NextPod 这 
个 函数 指针 来 从 上 述 队 列 中 消费 一 个 元 素 ， 下 面 是 相关 代码 片段 (来 自 
ConfigFactory 的 CreateFromKeys 方 法 中 创建 sheduler.Config 的 代码 ) : 





NextPod: func() *api.Pod { 
pod := f.PodQueue.Pop().(*api.Pod) 
glog.V(2).Infof("About to try and schedule pi 
return pod 


ty 


然后 ， 这 个 PodQueue 是 怎样 被 消费 的 呢 ?” 束 在 之 前 提 到 的 
Scheduler.scheduleOne 的 方法 里 ， 每 次 调用 NextPod 方 法 会 获取 一 个 可 用 
的 Pod， 然 后 交 给 genericScheduler 进 行 调度 ， 下 面 是 相关 代码 片段 (省 
略 了 其 他 代码 〉: 





pod := s.config.NextPod() 
if s.config.BindPodsRateLimiter != nil { 
s.config.BindPodsRateLimiter .Accept() 


} 


dest, err := s.config.Algorithm.Schedule(pod, s.config.M. 


genericScheduler.Schedule 方 法 只 是 给 出 该 Pod 调 度 到 的 目标 Node， 
如 果 调 度 成 功 ， 则 设置 该 Pod 的 spec.nodeName 为 目标 Node， 然 后 通过 
HTTP Rest 调 用 写 入 Kubernetes API Server 里 完成 Pod 的 Binding 操 作 ， 最 
后 通知 ConfigFactory 的 modeler (具体 实例 对 应 
scheduler.SimpleModeler) ， 将 此 Pod 放 入 Assumed Pod 队 列 ， 下 面 是 相 
关 代 码 片 段 : 





s.config.Modeler.LockedAction(func() { 
bindingStart := time.Now() 
err := s.config.Binder.Bind(b) 
metrics.BindingLatency.Observe(metrics.Sincel 
s.config.Recorder.Eventf(pod, "scheduled", "S 
// tell the model to assume that this binding 
assumed := *pod 
assumed.Spec.NodeName = dest 


s.config.Modeler .AssumePod(&assumed ) 


}) 


当 Pod 执 行 Bind 操 作成 功 以 后 ，Kubernetes API Server 上 Pod 己 经 满 
足 “ 已 调度 ”的 条 件 ， 因 为 spec.nodeName 已 经 被 设置 为 目标 Node 地 址 ， 
此 时 ConfigFactory 的 scheduledPodPopulator 这 个 Controller 就 会 监听 到 此 
变化 ， 将 此 Pod 从 modeler 中 的 Assumed 队 列 中 删除 ， 下 面 是 相关 代码 搬 
Py: 





framework.ResourceEventHandlerFuncs{ 
AddFunc: func(obj interface{}) { 
if pod, ok := obj.(*api.Pod); 
c.modeler .LockedActio 


c.modeler.For 


t) 


ty 


谷歌 的 大 神 在 源码 中 说 明 Modeler 的 存在 是 为 了 调度 的 优化 ， 那 么 
这 个 优化 具体 体现 在 哪里 昵 ? 由 于 Rest Watch API 存 在 延 时 ， 当 前 已 经 
调度 好 的 Pod 很 可 能 还 未 被 通知 给 Scheduler， 于 是 大 神灵 光一 内 : 为 每 
个 刚刚 调度 完成 的 Pod 发 放 一 个 “和 暂住证"， 安 排 “ 暂 住 ” 到 “Assumed” 队 列 
里 ， 然 后 设计 一 个 获取 当前 “已 调度 ”的 Pod 队 列 的 新 方法 ， 该 方法 合并 
Assumed 队 列 与 Watch 绥 存 队 列 ， 这 样 一 来 ， 就 得 到 了 最 佳 答案 。 如 果 
你 打算 看 看 这 段 代 码 ， 那 么 它 就 在 SimpleModeler 的 listPods 方 法 里 ， 至 
此 ， 你 若 也 完全 明白 了 c.PodLister=modeler.PodLister O) 这 人 名 简单 却 又 





深奥 的 代码 ， 那 么 茶 乾 你， 你 离 大 神 的 距离 又 缩短 了 一 个 厘米 。 


接 下 来 ， 我 们 深入 分 析 Pod 调 度 中 所 用 到 的 流 控 技 术 ， 缘 起 于 下 面 
这 段 代 码 : 


if s.config.BindPodsRateLimiter != nil { 


s.config.BindPodsRateLimiter .Accept( ) 


上 述 代 码 中 的 BindPodsRateLimiter 采 用 了 开源 项 目 ， 项 
目 ratelimit， 项 目地 址 为 https://github.com/juju/ratelimit， 它 实现 了 一 个 高 
te ne A 
令 牌 桶 流 控 算 法 的 原理 示意 图 。 


生产 者 线程 
r tokens/sec 


bucket holds up to 
b tokens 





packets token 
EARR” wait 


图 6.6 令 牌 棚 流 控 算 法 示意 图 


do work 


简单 地 说 ， 控 制 线程 以 固定 速率 同一 个 固定 容量 的 桶 《Bucket) 中 
BUMS HH (Token) ， 消 费 者 线程 则 等 竺 并 获取 到 一 个 令 牌 后 才能 继续 


接 下 来 的 任务 ， 人 否则 需要 等 待 可 用 令 牌 的 到 来 。 有 具体 次 来 ， 假 如 用 户 配 
置 的 平均 限 流 速率 为 r， 则 每 隔 1 秒 就 会 有 一 个 令 牌 被 加 入 桶 中 ， 而 令 
牌 桶 最 多 可 以 存储 b 个 令 牌 ， 如 宁 令 牌 到 达 时令 牌 桶 已 经 满 了 ， 那 么 这 
个 令 牌 会 被 于 和 并。 从 长 期 运行 结果 来 看 ， 消 费 者 的 处 理 速率 和 被 限 制 成 营 
量 r。 令 牌 桶 流 控 算法 除了 能 够 限制 平均 处 理 速度 ， 还 允许 茶 种 程度 的 
RREK, 








juju 的 ratelimit 模 块 通过 下 面 的 API 提 供 了 构造 一 个 令 牌 桶 的 简单 做 
法 ， 其 中 ，rate 参 数 表示 每 秒 填充 到 桶 里 的 令 牌 数量 ，capacity 则 是 桶 的 


ZJN 


E, 
Æ: 
func NewBucketWithRate(rate float64, capacity int64) *B 


我 们 回头 再 看 看 Kubernetes SchedulerServer 中 BindPodsRateLimiter 的 
赋值 代码 : 
c.BindPodsRateLimiter=util.NewTokenBucketRateLimiter (BindPodsQps, 
BindPodsBurst) ， 跟 踪 进 去， 发 现 它 束 是 调用 了 刚才 所 提 到 的 juju 函 数 
limiter: =ratelimit.NewBucketWithRate (float64 (gps) ， 
int64 (burst) ) ， 其 中 qps 目 前 为 常量 15， 而 burst 为 20， 目 前 在 
Kubernetes 1.0 版 本 中 还 没有 提供 命令 行 参数 来 配置 此 变量 ,会 在 未 来 的 
版 本 中 实现 。 








最 后 ， 我 们 一 起 深入 分 析 Kubernetes Scheduer Server 中 关于 Pod 调 度 
的 细节 。 首 先 ， 我 们 需要 理解 启动 过 程 中 SchedulerServer 加 载 调度 策略 
相关 配置 的 这 段 代 码 : 


predicateFuncs, err := getFitPredicateFunctions(predicat' 


priorityConfigs, err := getPriorityFunctionConfigs(p 


algo := scheduler .NewGenericScheduler(predicateFuncs, pr 


这 里 加 载 了 两 组 策略 ， 其 中 predicateFuncs 是 一 个 Map ，key 为 
FitPredicate 的 名 称 ，value 为 对 应 的 algorithm.FitPredicate 函 数 ， 它 表明 一 
个 候选 的 Node 是 否 满 足 当 前 Pod 的 调度 要 求 ，FitPredicate 函 数 的 具体 定 
义 如 下 : 


type FitPredicate func(pod *api.Pod, existingPods []*api 





FitPredicate 是 Pod 调 度 过 程 中 必须 满足 的 规则 ， 只 有 顺利 通过 由 所 
有 FitPredicate 组 成 的 这 道 封 锁 线 ， 一 个 Node 才 能 拿 到 主 会 场 的 * 入 场 
券 ”， 成 为 一 个 合格 的 “候选 人 ”， 等 待 下 一步 “评审 ”。 目 前 系统 提供 的 
具体 的 FitPredicate 实 现 都 在 predicates.go 里 ， 系 统 默认 加 载 注册 
FitPredicate 的 地 方 在 defaultPredicates 方 法 里 。 


当 有 一 组 Node 通 过 得 得 成 为 “候选 人 ”之 后 ， 需 要 有 一 种 办 法 来 选 
择 “ 最 优 ” 的 Node， 这 就是 接 下 来 我 们 要 介绍 的 priorityConfigs 所 要 做 的 
事情 了 。priorityConfigs 是 一 个 数组 ， 类 型 为 algorithm.PriorityConfig， 
PriorityConfig 包 括 一 个 PriorityFunction 函 数 ， 用 来 计算 并 给 出 一 组 Node 
的 优先 级 ， 下 面 是 相关 代码 : 





type PriorityConfig struct { 
Function PriorityFunction 
Weight int 
} 
type PriorityFunction func(pod *api.Pod, podLister PodLi 


type HostPriorityList []HostPriority 


func (h HostPriorityList) Len() int { 
return len(h) 
} 
func (h HostPriorityList) Less(i, j int) bool { 
if h[i].Score == h[j].Score { 
return h[i].Host < h[j].Host 


} 


return h[i].Score < h[j].Score 


如 有 果 看 到 这 里 还 是 不 太 明 白 它 的 用 途 ， 那 么 认真 读 一 读 下 面 这 上 段 来 
目 genericScheduler 的 计算 候选 季 点 优先 级 的 PrioritizeNodes 方 法 ， 你 就 
能 顿悟 了 : 一 个 候选 节点 的 优先 级 总 分 是 所 有 评委 老师 
(PriorityConfig) 一 起 给 出 的 “加 权 总 分 ”， 评 委 老 师 越 是 德高望重 
(PriorityConfig.Weight 越 大 ) ， 他 的 评分 影响 力 就 越 大 : 








combinedScores := map[string]int{} 
for _, priorityConfig := range priorityConfigs { 

weight := priorityConfig.Weight 

// skip the priority function if the weight is sj 


if weight == 0 { 


continue 
} 
priorityFunc := priorityConfig.Function 
prioritizedList, err := priorityFunc(pod, podLis 
if err != nil { 


return algorithm.HostPriorityList{}, err 


} 
for _, hostEntry := range prioritizedList { 


combinedScores[hostEntry.Host] += hostEntry.: 


} 

} 

for host, score := range combinedScores { 
glog.V(10).Infof("Host %s Score %d", host, score 
result = append(result, algorithm.HostPriority{H 

} 


return result, nil 


接 下 来 ， 我 们 看 看 系统 初始 化 加 载 的 默认 的 Predicate 与 Priorities 有 
哪些 ， 通 过 追踪 代码 ， 我 们 发 现 默认 加 载 的 代码 位 于 
plugin/pkg/scheduler/algorithmprovider/default/default.gofJinitex 20 Œ. : 


func init() { 
factory.RegisterAlgorithmProvider(factory.DefaultProv 
// EqualPriority is a prioritizer function that gives 
// Register the priority function so that its availab 
// but do not include it as part of the default prior 


factory.RegisterPriorityFunction("EqualPriority", schi 


跟踪 进去 后 ， 我 们 看 到 系统 默认 加 载 的 predicates 有 如 下 几 种 : 


e PodFitsResources; 


e MatchNodeSelector; 


e HostName。 
而 默认 加 载 的 priorities 则 有 如 下 几 种 : 


e LeastRequestedPriority; 
e BalancedResourceAllocation; 


e ServiceSpreadingPriority 。 











从 上 述 这 些 信息 来 看 ，Kubernetes 默 认 的 调度 指导 原则 是 尽量 均 色 
分 布 Node 到 不 同 的 Node 上 ， 并 且 确 保 各 个 Node 上 的 资源 利用 Se 
持 一 致 ， 也 就 是 说 如 果 你 有 100 台 机 器 ， 则 可 能 每 个 机 器 都 被 调度 到 ， 
而 不 是 只 有 其 中 的 20% 被 调度 到 ， a ak a 
资源 ， 这 不 正 是 所 谓 的 “韩信 点 兵 ， 多 多 益 善 ? 么 





接 下 来 我 们 以 服务 杀 和 性 这 个 默认 没有 加 载 的 Predicate 为 例 ， 看 看 
Kubernetes 是 如 何 通 过 Policy 文 件 注册 加 载 它 的 。 下 面 是 我 们 定义 的 一 个 
Policy 文 件 : 


"kind" : "Policy", 
"version" : "vi", 
"predicates" : [ 
{"name" : "RegionZoneAffinity", "argument" : 
], 
"priorities" : [ 


{"name" : "RackSpread", "weight" : 1, "argume 


Affinity" : {"label" : "rack"}}} 
] 


首先 ， 这 个 文件 被 映射 成 api.Policy 对 象 
(plugin/pkg/scheduler/api/types.go) 。 下 面 是 其 结构 体 定 义 : 


type Policy struct { 
api.TypeMeta ~“json:",inline"~ 
// Holds the information to configure the fit predica 
Predicates []PredicatePolicy ~“json:"predicates"- 
// Holds the information to configure the priority fu 


Priorities []PriorityPolicy ~“json:"priorities"- 


我 们 看 到 policy 文 件 中 的 predicates 部 分 被 映射 为 PredicatePolicy 数 
组 : 


type PredicatePolicy struct { 
Name string ~json:"name"~ 


Argument *PredicateArgument ‘json:"argument"’ 


而 PredicateArgument 的 定义 如 下 ， 包 括 服务 杀 和 性 的 相关 属性 
ServiceAffinity: 


type PredicateArgument struct { 


ServiceAffinity *ServiceAffinity ‘json:"serviceAffini 


LabelsPresence *LabelsPresence ~json:"labelsPresence" 


策略 文件 被 映射 为 api.Policy 对 象 后 ，PredicatePolicy 部 分 的 处 理 逻 
辑 则 交 给 下 面 的 函数 进行 处 理 
(plugin/pkg/scheduler/factory/plugin.go) : 


func RegisterCustomFitPredicate(policy schedulerapi.Pred 
var predicateFactory FitPredicateFactory 
var ok bool 
validatePredicateOrDie(policy) 
// generate the predicate function, if a custom type 
if policy.Argument != nil { 
if policy.Argument.ServiceAffinity != nil { 
predicateFactory = func(args PluginFa 
return predicates .NewServiceA 
args.PodLister, 
args.ServiceLister, 
args.NodeInfo, 


policy.Argument.Servi 


} 


} else if policy.Argument.LabelsPresence != n 
predicateFactory = func(args PluginFa 
return predicates.NewNodeLabe 


args.NodeInfo, 


policy.Argument.Label 


policy.Argument.Label 


在 上 面 的 代码 中 ， 当 ServiceAffinity 属 性 不 空 时 ， 就 会 调用 
predicates.NewServiceAffinityPredicate 方 法 来 创建 一 个 处 理 服务 亲 和 性 的 
FitPredicate， 随 后 被 加 载 到 全 局 的 predicateFactory 中 生效 。 


最 后 ，genericScheduler.Schedule 方 法 才 是 真正 实现 Pod 调 度 的 方 
法 ， 我 们 看 看 这 段 完整 代码 : 


func (g *genericScheduler) Schedule(pod *api.Pod, minion 
minions, err := minionLister.List() 
if err != nil { 
return "", err 
} 
if len(minions.Items) == 0 { 


return "", ErrNoNodesAvailable 


filteredNodes, failedPredicateMap, err := findNodesT 
if err != nil { 


return "", err 


priorityList, err := PrioritizeNodes(pod, g.pods, g. 
if err != nil { 
return "", err 
} 
if len(priorityList) == © { 
return "", &FitError{ 
Pod: pod, 


FailedPredicates: failedPredicateMap, 


return g.selectHost(priorityList) 


这 上 段 代 人 码 已 经 简单 得 不 能 再 简单 了 ， 因 为 该 干 的 活 都 已 经 被 
predicates 与 priorities 干 完了 ! 架构 之 美 ， 束 在 于 程序 逻辑 分 解 得 恰 到 好 
处 ， 每 个 组 件 各 司 其 职 ， 从 而 化 繁 为 简 ， 使 得 主体 流程 清晰 直观 ， 犹 如 
行云流水 ， 一 气 呵 成 。 


问 谷 歌 大 神 们 致敬 ! 


6.4.3 ”设计 上 总结 


与 之 前 的 Kubernetes API Server 和 Kubernetes Controller Mangager 对 
比 ，Kubernetes Scheduler Server 的 设计 和 代码 显得 更 为 “精妙 ”。 项 目 中 
引入 ratelimit 组 件 来 解决 Pod 调 度 的 流 控 问题 的 做 法 ， 既 大 大 简化 了 代码 
量 ， 叉 体现 了 大 神 们 的 气度 。 








Kubernetes Scheduler Server 的 一 个 关键 设计 目标 是 “插件 化 ”， 以 方 
{Cloud Provider 或 者 个 人 用 户 根 据 自 己 的 需求 进行 定制 ， 本 节 我 们 围绕 
其 中 最 为 关键 的 “FitPredicate 与 PriorityFunction” 对 其 设计 做 一 个 总 结 。 

如 图 6.7 所 示 ， 在 plugin.go 中 采用 了 全 局 变量 的 Map 变 量 记 录 了 系统 当前 
注册 的 FitPredicate 与 PriorityFunction， 其 中 fitPredicateMap 和 
priorityFunctionMap 分 别 存放 FitPredicateFactory 与 

PriorityConfigFactory 〈 包 含 了 PriorityFunctionFactory 的 一 个 引用 ) F. 
可 以 看 出 ， 这 里 的 设计 采用 了 标准 的 工厂 模式 ， 
factory.PluginFactoryArgs 这 个 数据 结构 可 以 认为 是 一 个 上 下 文 环境 变 
量 ， 它 提供 给 PluginFactory 必 要 的 数据 访问 接口 ， 比 如 获取 一 个 Node 的 
详细 信息 并 获取 一 个 Pod 上 的 所 有 Service 信 息 等 ， 这 些 接口 可 以 被 某 些 
具体 的 FitPredicate 或 PriorityFunction 使 用 ， 以 实现 特定 的 功能 ， 如 图 6.7 
所 示 的 predicates.PodFitsPods 和 priorities.LeastRequestedPriority 就 分 别 使 
用 了 上 述 接口 。 
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图 6.7 Kubernetes Scheduler Server 调 度 策略 相关 设计 示意 
图 


我 们 注意 到 PluginFactoryArgs 的 接口 都 是 Kubernetes 的 资源 访问 接 
口 ， 那 么 问题 就 来 了 ， 为 何不 直接 用 Kubernetes RestClient API 访 问 呢 ? 
一 个 主要 的 原因 是 如 果 这 样 做 ， 则 增加 了 插件 开发 者 开发 和 调 测 的 难 
度 ， 因 为 开发 者 需要 再 去 学 习 和 掌握 RestClient; 男 外 一 个 原因 是 效率 
的 问题 ， 如 果 大 家 都 采用 框 染 提供 的 “标准 方法 ”查询 资源 ， 那 么 框架 可 
以 实现 很 多 优化 ， 比 较 容易 缓存 ， 最 后 一 个 原因 则 与 之 前 我 们 分 析 
的 “Assumed Pod” 有 关 ， 即 查询 当前 已 经 调度 过 的 Pod 列 表 是 有 其 特殊 性 
的 ，PluginFactoryArgs 中 的 PodLister 方 法 就 是 引用 了 ConfigFactory 的 
PodLister。 











algorithmProviderMap 这 个 全 局 变量 则 保存 了 一 组 命名 的 调度 策略 配 


置 文件 (AlgorithmProviderConfig) ， 其 实 就 是 一 组 FitPredicate 与 
PriorityFunction 的 集合 ， 其 定义 如 下 : 


type AlgorithmProviderConfig struct { 
FitPredicateKeys util.StringSet 


PriorityFunctionkeys util.StringSet 


它 的 作用 是 预 配置 和 自 定 义 调度 规则 ，Kubernetes Scheduler Server 
默认 加 载 了 一 个 名 为 “DefaultProvider” 的 调度 策略 配置 ， 通 过 定义 和 加 
载 不 同 的 调度 规则 配置 文件 ， 我 们 可 以 改变 默认 的 调度 策略 ， 比 如 我 们 
可 以 定义 两 组 规则 文件 :其 中 一 个 命名 为 “function_test_cfg”， 面 癌 功 能 
测试 ， 调 度 原则 是 尽量 在 最 少 的 机 器 上 调度 Pod 以 节省 资源 ;另外 一 个 
则 命名 为 performance_test_cfg”， 面 癌 性 能 测试 ， 调 度 原 则 是 尽 可 能 使 用 
更 多 的 机 器 ， 以 测试 系统 性 能 。 














顺便 提 一 下 ， 笔 者 认为 在 Kubernetes Scheduler Server 中 关于 
PredicateArgument/PriorityArgument 的 设计 并 不 好 ， 这 里 没有 将 Predicate 
的 属性 通用 化 ， 比 如 采用 key-value 这 种 模式 ， 因 此 导致 Policy 文 件 格式 
与 Predicate/Priority 关 联 之 间 的 强 耘 合 性 ， 增 加 了 代码 理解 的 困难 性 ， 之 
前 分 析 的 Policy 文 件 中 服务 杀 和 性 的 Predicate 的 加 载 逻 辑 即 反映 了 这 个 
问题 ， 笔 者 深信 ， 未 来 版 本 中 大 神 们 会 认真 考虑 重 构 问 题 。 


至 些 ，Master 节 点 上 的 进程 的 源码 都 已 经 分 析 完 毕 ， 我 们 发 现 这 些 
进程 所 做 的 事情 ， 归 根 到 底 束 是 两 件 事 : Pod 调 度 + 智能 纠 错 ， 这 也 是 为 
什么 这 些 进 程 所 在 的 节点 被 称 为 “Master"”， 因 为 它们 高 高 在 上 上， 运筹 帷 
WE. HEIR Master" AAR ATR HARALD, {ASS Se. AS 
机 ， 计 算 机 的 世界 果然 比 我 们 人 类 的 世界 要 单纯 、 高 效 很 多 ， 真 心 希 望 








人 工 智 能 的 发 展 不 会 让 它们 的 世界 也 变 得 扑朔迷离 。 


6.5 “kubeletj 进 程 源码 分 析 





kubelet 是 运行 在 Minion 节 点 上 的 重要 守护 进程 ， 是 工作 在 一 线 的 重 
要 “工人 ”， 它 才 是 负责 “实例 化 ”和 ?月 动 ”一 个 具体 的 Pod 的 幕后 主导 ， 
并 且 掌 管 着 本 节点 上 的 Pod 和 容器 的 全 生命 周期 过 程 ， 定 时 间 Master 汇 
报 工 作 情 况 。 此 外 ，kubelet 进 程 也 是 一 个 “Server" 进 程 ， 它 默认 监听 
10250 端 口 ， 接 收 并 执行 远程 (Master) 发 来 的 指令 。 


下 面 我 们 分 别 对 其 启动 过 程 、 关 键 代码 分 析 及 设计 总 结 等 方面 进行 
深入 分 析 和 讲解 。 


6.5.1 ”进程 启动 过 程 


kubelet 进 程 的 入 口 类 源码 位 置 如 下 : 


github/com/GoogleCloudPlatform/kubernetes/cmd/kubelet/ku 


入 口 main ©) 函数 的 逻辑 如 下 : 


func main() { 
runtime .GOMAXPROCS( runtime .NumCPU( ) ) 
s := app.NewKubeletServer() 
s.AddFlags(pflag.CommandLine ) 
util.InitFlags() 
util.InitLogs() 
defer util.FlushLogs() 
verflag.PrintAndExitIfRequested() 
if err := s.Run(pflag.CommandLine.Args()); err != nil 
fmt.Fprintf(os.Stderr, "%v\n", err) 


os.Exit(1) 
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达 99%， 这 至 少 说 明 一 点 : AES PED aR, NEAS 
的 代码 看 起 来 就 好 像 出 自 一 个 人 之 手 。 我 们 先 来 看 看 KubeletServer 这 个 


结构 体 所 包括 的 属性 吧 ， 这 些 属性 可 以 分 为 以 下 几 组 。 


1) 基本 配置 


KubeConfig: kubelet 默 认 配 置 文件 路 径 。 
Address、Port、ReadOnlyPort、CadvisorPort、HealthzPort、 
HealthzBindAddress: 为 kubelet 绑 定 监 听 的 地 址 ， 包 括 自 身 Server 的 
地 址 ，Cadvisor 绑 定 的 地 址 ， 以 及 上 自 喘 健康 检查 服务 的 绑 定 地 址 


A 
等 。 








RootDirectory、CertDirectory: kubelet 默 认 的 工作 目录 
(/var/lib/kubelet) ， 用 于 存放 配置 及 VM 卷 等 数据 ，CertDirectory 
用 于 存放 证 书目 录 。 


2) 管理 Pod 和 容器 相关 的 参数 


PodInfraContainerImage: Pod 的 ipfra 容 器 的 镜像 名 称 ， 谷 歌 被 屏蔽 

的 时 候 可 以 换 成 自己 的 私有 仓库 的 镜像 名 。 

CgroupRoot: 可 选项 ， 创 建 Pod 的 时 候 所 使 用 的 顶层 的 cgroop 名 字 
(Root Cgroup) 。 

ContainerRuntime, DockerDaemonContainer, SystemContainer: 这 

三 个 参数 分 别 表示 选择 什么 容器 技术 (Docker 或 者 RKT) ~ Docker 

Daemon 容 器 的 名 凶 及 可 选 的 系统 资源 容器 名 称 ， 用 来 将 所 有 非 

kernel 的 、 不 在 容器 中 的 进程 放 入 此 容器 中 。 


3) 同步 和 自动 运 维 相 关 的 参数 


SyncFrequency、 FileCheckFrequency、 HTTPCheckFrequency: Pod 
容器 同步 周期 、 当 前 运行 的 容器 实例 分 别 与 Kubernetes 注 册 表 中 的 
诗 息 、 本 地 的 Pod 定 义 文件 及 以 HTTP 方 式 提供 信息 的 数据 源 进行 对 





比 同步 。 
e RegistryPullQPS、RegistryBurst: 从 注册 表 拉 取 竺 创建 的 Pod 列 表 时 


的 流 控 参 数 。 
e NodeStatusUpdateFrequency: kubelet 多 久 汇报 一 次 当前 Node 的 状 
太 
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ImageGCHighThresholdPercent. ImageGCLowThresholdPercent, 
LowDiskSpaceThresholdMB: 分 别 是 Image 镜 像 占用 磁盘 空间 的 高 
低 水 位 国 值 及 本 机 磁盘 最 小 空闲 容量 ， 当 可 用 容量 低 于 这 个 容量 
时 ， 上 所 有 新 Pod 的 创建 请 求 会 被 拒绝 。 


e MaxContainerCount. MaxPerPodContainerCount: 分 别 是 maximum- 








dead-containers 与 maximum-dead-containers-per-container， 表 示 保 留 
多 少 个 死亡 容器 的 实例 在 磁盘 上 ， 因 为 每 个 实例 都 会 占用 一 定 的 磁 
盘 ， 所 以 需要 控制 ， 默 认 是 MaxContainerCount 为 100， 
MaxPerPodContainerCount 为 2， 即 每 个 容器 保留 最 多 两 个 死亡 实 
例 ， 每 个 Node 保 留 最 多 100 个 死亡 实例 。 


只 要 分 析 一 下 上 述 KubeletServer 结 构 体 的 关键 属性 ， 我 们 就 可 以 得 
到 这 样 一 个 推论 : kubelet 进 程 的 “工作 量 ” 还 是 很 饱满 的 ， 一 点 都 不 比 
Master 上 的 API Server、Controll Manager、Scheduer 做 得 少 。 








在 继续 下 面 的 代码 分 析 之 前 ， 我 们 先 要 理解 这 里 的 一 个 重要 概 
念 *Pod Source”， 它 是 kubelet 用 于 获取 Pod 定 义 和 描 述 信 息 的 一 个 “数据 
源 ”，kubelet 进 程 查 询 并 监听 Pod _ Source 来 获取 属于 自己 所 在 节点 的 Pod 
列表 ， 当 前 文 持 三 种 Pod Source 类 型 。 





e Config File: 本 地 配置 文件 作为 Pod 数 据 源 。 
。 Http URL: Pod 数 据 源 的 内 容 通过 一 个 HITP URL 方 式 获 取 。 
e Kubernetes API Server: 默认 方式 ， 从 API Server 获 取 Pod 数 据 源 。 


进程 根据 启动 参数 创建 了 KubeletServer 以 后 ， 调 用 KubeletServer 的 
run 方 法 ， 进 入 局 动 流程 ， 在 流程 的 一 开始 首先 设置 了 自身 进程 的 
oom_adj 参 数 〈 默 认为 -900) ， 这 是 利用 了 Linux 的 OOM 机 制 ， 当 系统 发 
生 OOM 时 ，oom_adj 的 值 越 小 ， 越 不 容易 被 系统 K 训 掉 。 


if err := util.ApplyOomScoreAdj(@0, s.OOMScoreAdj); err 上 


glog.Warning(err ) 


为 什么 在 之 前 的 Master 世 点 进程 上 都 没有 见 到 这 个 调用 ， 而 在 
kubelet 进 程 上 却 看 到 这 上段 逻辑 ? 答案 很 简单 ， 因 为 MasterT 点 不 运行 
Pod 和 容器 ， 主 机 资源 通常 是 稳定 和 宽裕 的 ， 而 Minion 节 点 由 于 需要 运 
行 大 量 的 Pod 和 容器 ， 因 此 容易 产生 OOM 问 题 ， 所 以 这 里 要 确保 “守护 
者 ”不 会 因此 而 被 系统 Kill 挥 。 


由 于 kubelet 会 跟 API Server 打 交道 ， 所 以 接 下 来 创建 了 一 个 Rest 
Client 对 象 来 访问 API Server。 随 后 ， 启 动 进 程 构造 了 cAdvisor 来 监控 本 
地 的 Docker 容 器 ，cAdvisor 具 体 的 创建 代码 则 位 于 
pkg/kubeletcadvisorcadvisor_linux.go 里 ， 引 用 了 
github.com/google/cadvisor 这 个 同样 属于 谷歌 开源 的 项 目 。 





接着 ， 初 始 化 CloudProvider， 这 是 因为 如 果 Kubernetes 运 行 在 某 个 
运营 商 的 Cloud 环 境 中 ， 则 很 多 环境 和 资源 都 需要 从 CloudProvider 中 获 
取 ， 比 如 在 创建 Pod 的 过 程 中 可 能 需要 知道 某 个 Node 的 真实 主机 名 。 





虽然 容器 可 以 绑 定 宿主 机 的 网 络 空间 ， 但 知 不 当 使 用 会 导致 系统 安 
全 漏洞 ， 所 以 KubeletServer 中 的 HostNetworkSources 的 属性 用 来 控制 哪 
些 Pod 人 允许 绑 定 宿主 机 的 网 络 空 间 ， 默 认 是 都 禁止 绑 定 。 举 例 说 明 ， 比 


如 设置 HostNetworkSources=api，http， 则 表明 当 一 个 Pod 的 定义 源 来 自 
Kubernetes API 某 个 HTTP URL 时 ， 则 人 允许 此 Pod 绑 定 到 宿主 





机 的 网 络 空间 。 这 行 代码 即 上 述 处 理 逻 辑 中 的 一 小 部 分 : 
hostNetworkSources, err := kubelet.GetValidatedSources(s 


接 下 来 加 载 数字 证 书 ， 如 果 没 有 提供 证 书 和 私 钥 ， 则 默认 创建 一 个 
目 签名 的 X509 证 书 并 保存 到 本 地 。 下 一 步 ， 创 建 一 个 Mounter 对 象 ， 用 
来 实现 容器 的 文件 系统 挂 载 功能 。 


接 下 来 的 这 段 代码 根据 指定 了 DockerExecHandlerName 参 数 的 值 ， 
确定 dockerExecHandler 是 采用 Docker 的 exec 命 令 还 是 nsenter 来 实现 ， 默 
认 采 用 了 Docker 的 exec 这 种 本 地 方式 ，Docker 从 1.3 版 本 开始 提供 了 exec 
指令 ， 为 进入 容器 内 部 提供 了 更 好 的 手段 。 





var dockerExecHandler dockertools.ExecHandler 
switch s.DockerExecHandlerName { 
case "native": 
dockerExecHandler = &dockertools.NativeExecHa 
case "nsenter": 
dockerExecHandler = &dockertools.NsenterExecHi 
default: 
log.Warningf ("Unknown Docker exec handler %q; 


dockerExecHandler = &dockertools.NativeExecHa 


至 此 ， 程 序 构 造 了 一 个 KubeletConfig 结 构 体 ，90% 的 变量 与 之 


(Ni 
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前 的 KubeletServer 一 样 ， 这 让 代码 长 度 增 加 了 20 多 行 ! 定 睛 一 看 ， 源 码 
上 有 TODO 注 释 :“ 它 应 该 可 能 被 合并 到 KubeletServer 里 .……”， 目 测 注 
释 是 男 外 一 个 大 神 添加 的 ， 这 让 笔者 陷入 了 深 深 的 思考 : 难道 谷歌 的 绩 
效 考评 系统 中 也 有 恶俗 的 代码 行 数 考 核 指标 ? 


KubeletConfig 创 建 好 以 后 作为 参数 调用 RunKubelet (&kcfg, nil) 
方法 ， 程 序 运 行 到 这 里 ， 才 真正 进入 流程 的 核心 步骤 。 下 面 这 段 代 码 表 
明 kubelet 会 把 上 自己 的 事件 通知 API Server: 


eventBroadcaster := record.NewBroadcaster() 
kcfg.Recorder = eventBroadcaster.NewRecorder(api.Eve 
eventBroadcaster .StartLogging(glog.V(3).Infof) 
if kcfg.KubeClient != nil { 
glog.V(4).Infof("Sending events to api server.") 
eventBroadcaster .StartRecordingToSink(kcfg.KubecC 
} else { 


glog.Warning("No api server defined - no events | 





接 下 来 ， 启 动 进程 进入 关键 函数 createAndInitKubelet 中 ， 这 里 首先 
创建 一 个 PodConfig 对 象 ， 并 根据 启动 参数 中 Pod Source 参 数 是 否 提供 ， 
来 创建 相应 类 型 的 Pod Source 对 象 ， 这 些 PodSource 在 各 种 协 程 中 运行 ， 
拉 取 Pod 信 息 并 汇总 输出 到 同一 个 Pod Channel 中 等 待 kubelet 处 理 。 创 建 
PodConfig 的 具体 代码 如 下 : 


func makePodSourceConfig(kc *KubeletConfig) *config.PodC 


// source of all configuration 


cfg := config.NewPodConfig(config.PodConfigNotificat 


// define file config source 
if kc.ConfigFile != "" { 
glog.Infof("Adding manifest file: %v", kc.Config 


config.NewSourceFile(kc.ConfigFile, kc.NodeName, 


// define url config source 
if kc.ManifestURL != "" { 
glog.Infof("Adding manifest url: %v", kc.Manifes 
config .NewSourceURL(kc.ManifestURL, kc.NodeName, 
} 
if kc.KubeClient != nil { 
glog.Infof("Watching apiserver") 
config.NewSourceApiserver(kc.KubeClient, kc.Node 


} 


return cfg 


然后 ， 创 建 一 个 kubelet 并 宣告 它 的 诞生 : 


k, err = kubelet.NewMainkubelet(....) 
k.BirthCry() 


接着， 触发 kubelet 开 局 垃圾 回收 协 程 以 清理 无 用 的 容器 和 镜像 ， 释 
放 磁 盘 空 间 ， 下 面 是 其 代码 片段 : 








// Starts garbage collection threads. 
func (kl *Kubelet) StartGarbageCollection() { 
go util.Forever(func() { 
if err := kl.containerGC.GarbageCollect(); err !: 
glog.Errorf("Container garbage collection fa 


I 


}, time.Minute) 


go util.Forever(func() { 
if err := kl.imageManager.GarbageCollect(); err 
glog.Errorf("Image garbage collection failed 


J 


}, 5*time.Minute) 


createAndInitKubelet 方 法 创建 kubelet 实 例 以 后 ， 返 回 到 RunKubelet 
方法 里 ， 接 下 来 调用 startKubelet 方 法 ， 此 方法 首先 启动 一 个 协 程 ， 让 
kubelet 处 理 来 自 PodSource 的 Pod Update 消 息 ， 然 后 启动 Kubelet Server, 
下 面 是 具体 代码 ; 





func startKubelet(k KubeletBootstrap, podCfg *config.Pod 
// start the kubelet 
go util.Forever(func() { k.Run(podCfg.Updates()) }, 


// start the kubelet server 
if kc.EnableServer { 


go util.Forever(func() { 


k.ListenAndServe(net.IP(kc.Address), kc.Port 
}, 9) 
} 
if kc.ReadOnlyPort > © { 
go util.Forever(func() { 


k.ListenAndServeReadOnly(net.IP(kc.Address), 
}, ©) 


至 此 ，kubelet 进 程 启动 完毕 。 


6.5.2 ”关键 代码 分 析 


6.5.1 节 里 ， 我 们 分 析 了 kubelet 进 程 的 局 动 流程 ， 大 致 明白 了 kubelet 
的 核心 工作 流程 就 是 不 断 从 PodSource 中 获取 与 本 节点 相关 的 Pod， 然 后 
开始 “加 工 处 理 "”， 所 以 ， 我 们 先 来 分 析 Pod Source 部 分 的 代码 。 前 面 我 
们 提 到 ，kubelet 可 以 同时 文 持 三 类 Pod ”Source， 为 了 能 够 将 不 同 的 Pod 
Source“ 汇 聚 ?到 一 起 统一 处 理 ， 谷 歌 特地 设计 了 PodConfig 这 个 对 象 ， 其 
代码 如 下 : 





type PodConfig struct { 
pods *podStorage 


mux *config.Mux 


// the channel of denormalized changes passed to listi 


updates chan kubelet.PodUpdate 


// contains the list of all configured sources 


sourcesLock sync.Mutex 


sources util.StringSet 
} 
其 中 ，sources 属 性 包括 了 当前 加 载 的 所 有 Pod Source 类 型 ， 


SourcesLock 是 source 的 排他 锁 ， 在 新 增 Pod ”Source 的 方法 里 使 用 它 来 避 
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当 Pod 发 生变 动 时 ， 例 如 Pod 创 建 、 删 除 或 者 更 新 ， 相 关 的 Pod 
Source 束 会 产生 对 应 的 PodUpdate 事 件 并 推送 到 Channel 上。 为 了 能 够 统 
一 处 理 来 自 多 个 Source 的 Channel， 谷 歌 设计 了 config.Mux 这 个 “聚合 
髓 ”， 它 负责 监听 多 路 Channel， 当 接收 到 Channel 发 来 的 事件 以 后 ， 交 给 
Merger 对 象 进行 统一 处 理 ，Merger 对 象 最 终 把 多 路 Channel 发 来 的 事件 
合并 写 入 updates 这 个 汇聚 Channel 里 等 待 处 理 。 








下 面 是 config.Mux 的 结构 体 定 义 ， 其 属性 sources 为 一 个 Channel 
Map，key 是 对 应 的 Pod Source 的 类 型 : 


type Mux struct { 
// Invoked when an update is sent to a source. 
merger Merger 
// Sources and their lock. 
sourceLock sync.RwWMutex 
// Maps source names to channels 


sources map[string]chan interface{} 


我 们 继续 深入 分 析 config.Mux 的 工作 过 程 ， 前 面 提 到 ，kubelet 在 启 
动 过 程 中 在 makePodSourceConfig 方 法 里 创建 了 一 个 PodConfig 对 象 ， 并 
且 根 据 启 动 参数 来 决定 要 加 载 哪 些 类 型 的 Pod Source， 在 这 个 过 程 中 调 
用 了 下 述 方法 来 创建 一 个 对 应 的 Channel: 





func (c *PodConfig) Channel(source string) chan<- interfi 
c.sourcesLock.Lock() 


defer c.sourcesLock.Unlock() 


c.sources.Insert(source) 


return c.mux.Channel(source) 


而 Channel 具 体 的 创建 过 程 则 在 config.Mux 里 ，Channel 创 建 完成 后 
被 加 入 config.Mux 的 sources 里 并 且 启 动 一 个 协 程 开始 监 昕 消息 ， 代 人 码 如 


func (m *Mux) Channel(source string) chan interface{} { 
if len(source) == 0 { 
panic("Channel given an empty name") 
} 
m.sourceLock.Lock() 
defer m.sourceLock.Unlock() 
channel, exists := m.sources[source] 
if exists { 
return channel 
} 
newChannel := make(chan interface{}) 
m.sources[source] = newChannel 
go util.Forever(func() { m.listen(source, newChannel 


return newChannel 


config.Mux 的 上 述 listen 方 法 很 简单 ， 就 是 监听 新 创建 的 Channel， 
旦 发 现 Channel 上 有 数据 就 交 给 Merger 进 行 处 理 : 


func (m *Mux) listen(source string, listenChannel <-chan 
for update := range listenChannel { 


m.merger.Merge(source, update) 


我 们 先 来 看 看 Pod ”Source 是 如 何 发 送 PodUpdate 事 件 到 上 自己 所 在 的 
Channel 上 的 ， 在 6.5.1 节 中 我 们 所 见 到 的 下 面 这 段 代 码 创 建 了 一 个 Config 
File 类 型 的 Pod Source: 


// define file config source 
if kc.ConfigFile != "" { 
glog.Infof("Adding manifest file: %v", kc.Config 


config.NewSourceFile(kc.ConfigFile, kc.NodeName, 


在 NewSourceFile 方 法 里 启动 了 一 个 协 程 ， 每 隔 指定 的 时 间 
(ke.FileCheckFrequency) 就 执行 一 次 SourceFile 的 run 方 法 ， 在 run 方 法 
里 所 调用 的 主体 逻辑 是 下 面 的 函数 : 





func (s *sourceFile) extractFromPath() error { 
path := s.path 
statInfo, err := os.Stat(path) 
if err != nil { 
if !os.IsNotExist(err) { 


return err 


// Emit an update with an empty PodList to al. 
s.updates <- kubelet.PodUpdatef{[]*api.Pod{}, 


return fmt.Errorf("path does not exist, ignor: 


switch { 
case statInfo.Mode().IsDir(): 
pods, err := s.extractFromDir (path) 
if err != nil { 
return err 


} 
s.updates <- kubelet.PodUpdate{pods, kubelet.: 


case statInfo.Mode().IsRegular(): 
pod, err := s.extractFromFile(path) 
if err != nil { 
return err 


} 
s.updates <-kubelet.PodUpdate{[]*api.Pod{pod} 


default: 


return fmt.Errorf("path is not a directory or 


return nil 


看 一 眼 上 面 的 代码 ， 我 们 就 大 致 明白 了 Config File 类 型 的 Pod Source 
是 如 何 工作 的 : 它 从 指定 的 目录 中 加 载 多 个 Pod 定 义 文件 并 转换 为 Pod 列 
表 或 者 加 载 单 个 Pod 定 义 文 件 并 转换 为 单个 pod， 然 后 生成 对 应 的 全 量 类 
型 的 PodUpdate 事 件 并 写 入 Channel 中 去 。 这 里 笔 考 也 发 现 了 代码 命名 的 
一 个 玻 漏 之 处 ，SourceFile 的 updates 属 性 其 实 应 该 被 命名 为 update。 其 他 
两 种 Pod Source 类 型 的 代码 解析 束 不 在 这 里 提 及 了 。 


接 下 来 我 们 分 析 Merger 对 象 ，PodConfig 里 的 Merger 对 象 其 实 是 一 
个 config.podStorage 实 例 ， 它 同时 是 PodConfig 的 pods 属 性 的 一 个 引用 。 
podStorage 的 源码 位 于 pkg/kubelet/config/config.go 里 ， 其 定义 如 下 : 


type podStorage struct { 
podLock sync.RWMutex 
// map of source name to pod name to pod reference 
pods map[string]map[string]*api.Pod 
mode PodConfigNotificationMode 
// ensures that updates are delivered in strict order 
// on the updates channel 
updateLock sync.Mutex 
updates chan<- kubelet.PodUpdate 
// contains the set of all sources that have sent at 
sourcesSeenLock sync.Mutex 
sourcesSeen util.StringSet 
// the EventRecorder to use 


recorder record.EventRecorder 


据 ， 


我 们 看 到 podStorage 的 关键 属性 解释 如 下 。 


(1) pods: 类 型 是 Map， 存 放 每 个 Pod Source 上 拉 过 来 的 Pod 数 
是 podStorage 当 前 保存 “全 量 Pod” 的 地 方 。 





(2) updates: 它 就 是 PodConfig 里 的 updates 属 性 的 一 个 引用 。 
(3) mode: 表明 podStorage 的 Pod 事 件 通知 模式 ， 有 以 下 几 种 。 


PodConfigNotificationSnapshot: 全 量 快照 通知 模式 。 
PodConfigNotificationSnapshotAndUpdates: 全 量 快 照 + 更 新 Pod 通 知 
模式 〈 代 码 中 创建 podStorage 实 例 时 采用 的 模式 ) 。 
PodConfigNotificationIncremental: 增 量 通知 模式 。 


podStorage 实 现 的 Merge 接 口 的 源码 如 下 : 


func (s *podStorage) Merge(source string, change interfa 

s.updateLock.Lock() 
defer s.updateLock.Unlock( ) 
adds, updates, deletes := s.merge(source, change) 
// deliver update notifications 
switch s.mode { 
case PodConfigNotificationSnapshotAnduUpdates: 

if len(updates.Pods) > © { 

s.updates <- *updates 
} 
if len(deletes.Pods) > © || len(adds.Pods) > 


s.updates<- kubelet.PodUpdate{s.Merge 





// 省 略 无 关 的 Case 逻 辑 
} 


return nil 











在 上 述 Merge 过 程 中 ， 先 调用 内 部 函数 merge， 将 Pod eu 
Channel 上 发 来 的 PodUpdate 事 件 分 解 为 对 应 的 新 增 、 更 新 及 删除 等 
PodUpdate 事 件 ， 然 后 判断 是 否 有 更 新 事件 ， 如 果 有 ， 则 直接 SICA 
的 Channel 中 (podStorage.updates) , %& Ja ii] H MergedState K 202 till — 

份 podStorage 的 当前 全 量 Pod 列 表 ， 以 此 产生 一 个 全 量 的 PodUpdate 事 件 
并 写 入 汇总 的 Channel 中 ， 从 而 实现 了 多 Pod Source Channel H QC RE 
辑 。 





分 析 完 Merger 过 程 以 后 ， 我 们 接 下 来 看 看 是 什么 对 象 ， 以 及 如 何 消 
费 这 个 汇总 的 Channel。 在 上 一 市 提 到 ， 在 kubelet 进 程 启动 的 过 程 中 调 
用 了 startKubelet 方 法 ， 此 方法 首先 启动 一 个 协 程 ， 让 kubelet 处 理 来 自 
PodSource 的 Pod Update 消 息 ， 即 下 面 这 行 代码 : 








go util.Forever(func() { k.Run(podCfg.Updates()) }, 0) 


其 中 ，PodConfig 的 Updates © 方法 返回 了 前 面 我 们 所 说 的 汇总 
Channel 变 量 的 一 个 引用 ， 下 面 是 kubelet 的 Run Cupdates<-chan 
PodUpdate) 方法 的 代码 : 


func (kl *Kubelet) Run(updates <-chan PodUpdate) { 
if kl.logServer == nil { 
kl.logServer = http.StripPrefix("/logs/", htt; 


} 


if kl.kubeClient == nil { 


} 


glog.Warning("No api server defined - no node 


// Move Kubelet to a container. 


if kl.resourceContainer != "" { 


} 


if err 


err := util.RunInResourceContainer(kl.resourc 
if err != nil { 

glog.Warningf("Failed to move Kubelet 
} 


glog.Infof("Running in container %q", kl.reso 


:= kl.imageManager.Start(); err != nil { 


kl.recorder.Eventf(kl.nodeRef, "kubeletSetupFailed", " 


if err 


if err 


if err 


glog.Errorf("Failed to start ImageManager, im 


:= kl.cadvisor.Start(); err != nil { 


kl.recorder.Eventf(kl.nodeRef, "kubeletSetupF 


glog.Errorf("Failed to start CAdvisor, system 


:= kl.containerManager.Start(); err != nil { 


kl.recorder.Eventf(kl.nodeRef, "kubeletSetupF 


glog.Errorf("Failed to start ContainerManager 


:= kl.oomwWatcher.Start(kl.nodeRef); err != nil 


kl.recorder.Eventf(kl.nodeRef, "kubeletSetupF 


glog.Errorf("Failed to start OOM watching: %v 


} 

go util.Until(kl.updateRuntimeUp, 5*time.Second, util.Ne' 
// Run the system oom watcher forever. 
k1.statusManager .Start() 


k1l.syncLoop(updates, kl) 





上 述 代码 首先 启动 了 一 个 HTTP File Server 来 远程 获取 本 节点 的 系统 
日 志 ， 接 下 来 根据 局 动 参数 的 设置 来 决定 是 人 否 在 指定 的 Docker 容 器 中 局 
动 kubelet 进 程 ( 如 果 成 功 ， 则 将 本 进程 转移 到 指定 的 容器 中 ) ， 然 后 分 
别 启 动 Image Manager( 人 负责 Image GC) 、cAdvisor (Docker 性 能 监 
控 ) 、Container Manager (Container GC) 、OOM Watcher (OOM 监 
测 ) ~ Status Manager( 人 负 员 同步 本 节点 上 Pod 的 状态 到 API Server 上 ) 
等 组 件 ， 最 后 进入 syncLoop 方 法 中 ， 无 限 循环 调用 下 面 的 
syncLooplteration 方 法 : 














func (kl *Kubelet) syncLoopIteration(updates <-chan PodU 
k1.syncLoopMonitor.Store(time.Now() ) 
if !kl.containerRuntimeUp() { 
time.Sleep(5 * time.Second) 
glog.Infof("Skipping pod synchronization, contai 
return 
} 
if !kl.doneNetworkConfigure() { 
time.Sleep(5 * time.Second) 
glog.Infof("Skipping pod synchronization, networ 


return 


} 
unsyncedPod := false 


podSyncTypes := make(map[types.UID]SyncPodType) 


select { 
case u, ok := <-updates: 
if !ok { 


glog.Errorf("Update channel is closed. Exiti 
return 
} 
kl.podManager .UpdatePods(u, podSyncTypes) 
unsyncedPod = true 
kl.syncLoopMonitor.Store(time.Now()) 
case <-time.After(kl.resyncInterval): 
glog.V(4).Infof("Periodic sync") 
} 
start := time.Now() 
// If we already caught some update, try to wait for 
// to possibly batch it with other incoming updates. 
for unsyncedPod { 
select { 
case u := <-updates: 
k1.podManager.UpdatePods(u, podSyncTypes ) 
k1.syncLoopMonitor.Store(time.Now() ) 
case <-time.After(5 * time.Millisecond): 
// Break the for loop. 


unsyncedPod = false 


} 


pods, mirrorPods := kl.podManager.GetPodsAndMirrorMa 

kl.syncLoopMonitor.Store(time.Now()) 

if err := handler.SyncPods(pods, podSyncTypes, mirro 
glog.Errorf("Couldn't sync containers: %v", err) 


} 


k1.syncLoopMonitor.Store(time.Now() ) 


在 上 述 代 码 中 ， 如 果 从 Channel 中 拉 取 到 了 PodUpdate 事 件 ， 则 先 调 
用 podManager 的 UpdatePods 方 法 来 确定 此 PodUpdate 的 同步 类 型 ， 并 将 
结果 放 入 podSyncTypes 这 个 Map 中 ， 同 时 为 了 提升 处 理 效率 ， 在 代码 中 
增加 了 持续 循环 拉 取 PodUpdate 数 据 直 到 Channe] 为 空 为 止 〈 超 时 判断 ) 
的 一 段 逻 辑 。 在 方法 的 最 后 ， 调 用 SyncHandler 接 口 来 完成 Pod 同 步 的 具 
体 逻 辑 ， 从 而 实现 了 PodUpdate 事 件 的 高 效 批 处 理 模 式 。 





SyncHandler 在 这 里 就 是 kubelet 实 例 本 里 ， 它 的 SyncPods 方 法 比较 
长 ， 其 主要 逻辑 如 下 。 


将 传 入 的 全 量 Pod， 与 statusManager 中 当前 保存 的 Pod 和 集合 进行 对 
比 ， 删 除 statusManager 中 当前 已 经 不 存在 的 Pod〈 和 孤儿 Pod) 。 

调用 kubelet 的 admitPods 方 法 以 过 滤 邱 不 适合 本 节点 创建 的 Pod。 此 
方法 首先 过 滤 挥 状态 为 Failed 或 者 Succeeded 的 Pod; 接着 过 小 挥 不 
适合 本 节点 的 Pod， 比 如 Host Port 冲 突 、Node Label 的 约束 不 匹配 及 
Node 的 可 用 资源 不 足 等 情况 ; 最 后 检查 磁盘 的 使 用 情况 ， 如 有 果 厂 盘 
的 可 用 空间 不 足 ， 则 过 滤 抒 所 有 Pod。 

e 对 上 述 过 小 后 的 Pod 集 合 中 的 每 一 个 Pod 调 用 podWorkers 的 


UpdatePod 方 法 ， 而 此 方法 内 部 创建 了 一 个 Pod 的 workUpdate 事 件 并 
发 布 到 该 Pod 对 应 的 一 个 WorkChannel 上 

(podWorkers.podWorkers) 。 
对 于 已 经 删除 或 不 存在 的 Pod， 通 知 podWorkers 删 除 相 关联 的 
WorkChannel (workUpdate) 。 
对 比 Node 当 前 运行 中 的 Pod 及 目标 Pod 列 表 , “ 杀 挤 ?多余 的 Pod， 并 
且 调 用 DockerRuntime (Docker Deamon 进 程 ) API， 重 新 获取 当前 
运行 中 的 Pod 列 表 信 息 。 
清理 “ 拆 儿 ”Pod 所 遗留 的 PV 和 磁盘 目录 。 








要 真正 理解 Pod 是 怎么 在 Node 上 “落地 ”的 ， 还 要 继续 深入 分 析 上 述 
第 3 步 的 代码 。 首 先 我 们 看 看 对 workUpdate 这 个 结构 体 的 定义 : 


type workUpdate struct { 
pod *api.Pod 
// The mirror pod of pod; nil if it does not exist. 
mirrorPod *api.Pod 
// Function to call when the update is complete. 
updateCompleteFn func() 


updateType SyncPodType 


其 中 的 属性 pod 是 当前 要 操作 的 Pod 对 象 ，mirrorPod 则 是 对 应 的 镜像 
Pod， 下 面 是 对 它 的 解释 : 








“对 于 每 个 来 自 非 API Server Pod Source 上 的 Pod，kubelet 都 在 API 
Server 上 注册 一 个 几乎 “一 模 一 样 *? 的 Po0d， 这 个 Pod 被 称 为 mirrorPod， 这 
样 一 来 ， 就 将 不 同 的 Pod ”Source 上 的 Pod 都 “统一 ”到 了 kubelet 的 注册 表 


上 ， 从 而 统一 了 Pod 生 命 周 期 的 管理 流程 。” 


workUpdate 的 updateCompleteFn 属 性 是 一 个 回调 函数 ，work 完 成 后 
会 执行 此 回调 函数 ， 在 上 述 第 3 步 中 ， 此 函数 用 来 计算 该 work 的 调度 时 
延 指标 。 





对 于 每 个 要 同步 的 pod，podWorkers 会 用 一 个 长 度 为 1 的 Channel 来 
存放 其 对 应 的 workUpdate， 而 属性 lastUndeliveredWorkUpdate 则 存放 最 
近 一 个 待 安排 执行 的 workUpdate， 这 是 因为 一 个 Pod 的 前 一 个 
workUpdate 正 在 执行 的 时 候 ， 可 能 会 有 一 个 新 的 PodUpdate 事 件 需 要 处 
理 。 理 解 了 这 个 过 程 后 ， 再 来 看 podWorkers 的 定义 ， 就 不 难 了 : 


type podworkers Struct { 
// Protects all per worker fields. 
podLock sync.Mutex 
podUpdates map[types.UID]chan workUpdate 
isWorking map[types.UID]bool 
lastUndeliveredworkUpdate map[types.UID]workUpdate 
runtimeCache kubecontainer .RuntimeCache 
syncPodFn syncPodFnType 


recorder record.EventRecorder 


下 面 这 个 函数 就 是 第 3 步 里 产生 workUpdate 事 件 并 放 入 到 
podWorkers 的 对 应 Channel 的 方法 的 源码 : 


func (p *podworkers) UpdatePod(pod *api.Pod, mirrorPod * 


uid := pod.UID 


var podUpdates chan workUpdate 
var exists bool 
updateType := SyncPodUpdate 
p.podLock.Lock( ) 
defer p.podLock.Unlock() 
if podUpdates, exists = p.podUpdates[uid]; !exists { 
podUpdates = make(chan workUpdate, 1) 
p.podUpdates[uid] = podUpdates 
updateType = SyncPodCreate 
go func() { 
defer util.HandleCrash() 
p .managePodLoop(podUpdates ) 
}() 


} 
if !p.isWorking[pod.UID] { 


p.isWorking[pod.UID] = true 

podUpdates <- workUpdate{ 
pod: pod, 
mirrorPod: mirrorPod, 
updateCompleteFn: updateComplete, 
updateType: updateType, 

} 

} else { 

p.lastUndeliveredworkUpdate[pod.UID] = workUp 
pod: pod, 
mirrorPod: mirrorPod, 


updateCompleteFn: updateComplete, 


updateType: updateType, 


上 面 的 代码 会 调用 podWorkers 的 managePodLoop 方 法 来 处 理 
podUpdates 队 列 ， 这 里 主要 是 获取 必要 的 参数 ， 最 终 处 理 又 转手 交 给 
SyncPodFn 方 法 去 处 理 。 下 面 是 managePodLoop 的 源码 : 


func (p *podworkers) managePodLoop(podUpdates <-chan wor 
var minRuntimeCacheTime time.Time 
for newwork := range podUpdates { 
func() { 
defer p.checkForUpdates(newwork.pod.UID, newWork.updateC 
if err := p.runtimeCache.ForceUpdateIfOlder (minRuntimeCa 
glog.Errorf("Error updating the container runtime cac 
return 
} 
pods, err := p.runtimeCache.GetPods() 
if err != nil { 
glog.Errorf("Error getting pods while syncing 
return 
} 
err = p.syncPodFn(newwork.pod, newWwor 
kubecontainer .Pods(pods) .FindPodByID(newwork.pod.UI 
if err != nil { 


glog.Errorf("Error syncing pod %s, skipping: %v", newWor 


p.recorder.Eventf(newwork.pod, "failedSync", "Error sync 
return 
} 
minRuntimeCacheTime = time.Now() 
newwork .updateCompleteFn() 
}() 


追踪 podWorkers 的 构造 函数 调用 过 程 ， 可 以 发 现 syncPodFn 函 数 其 
实 束 是 kubelet 的 syncPod 方 法 ， 这 个 方法 的 代码 量 有 点 儿 多 ， 主 要 逻辑 
如 下 。 








(1) 根据 系统 配置 中 的 权限 控制 ， 检 查 Pod 是 否 有 权 在 本 节点 运 
行 ， 这 些 权 限 包括 Pod 是 否 有 权 使 用 HostNetwork 〈 还 记得 之 前 分 析 的 代 
码 么 ? 由 Pod Source 类 型 决定 ) 、Pod 中 的 容器 是 否 被 授权 以 特权 模式 启 
动 (privileged mode) 等 ， 如 果 未 被 授权 ， 则 删除 当前 运行 中 的 旧版 本 
的 Pod 实 例 并 返回 错误 信息 。 


(2) 创建 Pod 相 关 的 工作 目录 、PV 存 放 目 录 、Plugin 插 件 目录 ， 这 
些 目录 都 以 Pod 的 UID 为 上 一 级 目录 。 


(3) 如 果 Pod 有 PV 定义 ， 则 针对 每 个 PV 执行 目录 的 mount 操 作 。 


(4) 如果 是 SyncPodUpdate 类 型 的 Pod， 则 从 DockerRuntime 的 API 
接口 查询 获取 Pod 及 相关 容器 的 最 新 状态 信息 。 





(5) 如 果 Pod 有 imagePullSecrets 属 性 ， 则 在 API ”Server 上 获取 对 应 
的 Secret。 


(6) 调用 Container Runtime 的 API 接 口 方 法 SyncPod， 实 现 Pod“ 真 
正 同步 ”的 逻辑 。 


(7) 如 果 Pod ”Source 不 来 自 API Server， 则 继续 处 理 其 关联 的 


mirrorPod. 


e 如 果 mirrorPod 跟 当前 Pod 的 定义 不 匹配 ， 则 它 会 被 删除 。 
e 如 果 mirrorPod 还 不 存在 《比如 新 创建 的 Pod) ， 则 会 在 API Server E 
新 建 一 个 。 


Kubernetes 中 Container 。” Runtime 的 默认 实现 是 Dockers， 对 应 类 是 
dockertools.DockerManager， 其 源码 位 于 
kg/kubelet/dockertools/manager.go 里 ， 在 上 述 kubelet.syncPod 方 法 中 所 调 
用 的 DockerManager 的 SyncPod 方 法 实现 了 下 面 的 逻辑 。 





。 判断 一 个 Pod 实 例 的 哪些 组 成 部 分 需要 重 局 : 包括 Pod 的 infra 容 器 是 
否 发 生变 化 (如 网 络 模式 、Pod 里 运行 的 各 个 容器 的 端口 是 否 发 生 
变化 ); Pod 里 运行 的 容器 是 否 发 生变 化 用 Probe 检 测 容 器 的 状态 
以 确定 容器 是 否 异 常 等 。 

。 根据 Pod 实 例 重启 结果 的 判断 ， 如 果 需 要 重启 Pod 的 infra 容 器 ， 则 先 
Kill ”Pod 然后 启动 Pod 的 infra 容 器 ， 设 定好 网 络 ， 最 后 启动 Pod 里 的 
所 有 Container; 否则 就 先 Kil 那 些 需要 重启 的 Container， 人 然后 重新 
局 动 它 们 。 注 意 ， 如 果 是 新 创建 的 Pod， 则 因为 找 不 到 Node 上 对 应 
的 Pod 的 infra 容 器 ， 所 以 会 被 当 作 重启 Pod 的 infra 容 器 的 多 辑 来 实现 
创建 过 程 。 








DockerManager 创 建 Pod 的 infra 容 器 的 逻辑 在 createPodInfraContainer 
方法 里 ， 大 体 逻 辑 如 下 。 


e 如 果 Pod 的 网 络 不 是 HostNetwork 模 式 ， 则 搜集 Pod 所 有 容器 的 Port 作 
为 infra 容 髓 所 要 暴露 的 Port 列 表 。 

e 如 果 infra 容 器 的 Image 目 前 不 存在 ， 则 尝试 拉 取 Image。 

。 创建 infra 的 Container 对 象 并 且 局 动 ranContainerInPod 方 法 。 

e 如 果 容 器 定 义 有 Lifecycle， 并 且 PostStart 回 调 方 法 被 设置 了 ， 束 会 
触发 此 方法 的 调用 ， 如 果 调 用 失败 则 K 记 容器 并 返回 。 

。 创建 一 个 软 连接 文件 指 问 容 器 的 日 志文 件 ， 此 软 连 接 文 件 名 包括 
Pod 的 名 称 、 容 占 的 名 称 及 容器 的 ID， 这 样 的 目的 是 让 ElasticSearch 
这 样 的 搜索 技术 容易 索引 和 定位 Pod 日 志 。 

。 如 果 此 容器 是 Podinfra 容 器 ， 则 设置 其 OOM 参 数 低 于 标准 值 ， 使 得 
它 比 其 他 容器 具备 更 强 的 “抗灾 ”能 力 。 

e 修改 Docker 生 成 的 容器 的 resolv.conf 文 件 ， 增 加 ndots 参 数 并 默认 设 
置 为 5， 这 是 因为 Kubermetes 默 认 假 设 的 域名 分 割 长 度 是 5， 例 如 
_dns._udp.kube-dns.default.svc. 








上 述 逻 辑 中 所 调用 的 runContainerInPod 是 DockerManager 的 核心 方法 
之 一 ， 不 管 是 创建 Pod 的 infra 容 器 还 是 Pod 里 的 其 他 容器 ， 都 会 通过 此 方 
法 使 得 容器 被 创建 和 运行 。 以 下 是 其 主要 逻辑 。 


。 生成 Container 必 要 的 环境 变量 和 参数 ， 比 如 ENV 环 境 变 量 、 
Volume Mounts 信 息 、 端 口 映 射 信 息 、DNS 服 务 器 信息 、 容 器 的 日 
志 目 录 、parent cgGroup 等 。 

e 调用 runContainer 方 法 完成 Docker “Container 实 例 的 创建 过 程 ， 简 单 
地 说 ， 就 是 完成 Docker create container 命 令 行 所 需 的 各 种 参数 的 构 
造 过 程 ， 并 通过 程序 来 调用 执行 。 

。 构造 HostConfig 对 象 ， 主 要 参数 有 目录 映射 、 端 口 映 射 等 、cgGroup 
的 设 定 等 ， 简 单 地 说 ， 束 是 完成 了 Docker start container 命 令 行 所 需 


的 必要 参数 的 构造 过 程 ， 并 通过 程序 来 调用 执行 。 


在 上 述 逻 辑 中 ，runContainer 与 startContainer 的 具体 实现 都 是 靠 
DockerManager 中 的 dockerClient 对 象 完成 的 ， 它 实现 了 DockerInterface 接 
口 ，dockerClient 的 创建 过 程 在 pkg/kubeleUydockertools/docker.go 里 ， 下 面 
是 这 段 代 码 : 


func ConnectToDockerOrDie(dockerEndpoint string) DockerI 
if dockerEndpoint == "fake://" { 
return &FakeDockerClient{ 


VersioniInfo: docker.Env{"ApiVersion=1 


} 
} 
client, err := docker.NewClient(getDockerEndpoint (doc 
if err != nil { 

glog.Fatalf("Couldn't connect to docker: %v", 
} 


return client 


这 里 的 dockerEndpoint 是 本 节点 上 的 Docker ”Deamon 进 程 的 访问 地 
址 ， 默 认 是 unix: /WW/var/run/docker.sock， 在 上 述 代码 中 使 用 了 来 自 开 源 
项 目 https://github.com/fsouza/go-dockerclient 提 供 的 Docker Client， 它 也 


是 Go 语言 实现 的 一 个 用 HTTP 访 问 Docker Deamon 提 供 的 标准 API 的 客户 
Dig HE AE o 


我 们 来 看 看 dockerClient 创 建 容器 的 具体 代码 (CreateContainer) : 


func (c *Client) CreateContainer(opts CreateContainerOpt. 


path := "/containers/create " + queryString(opts) 
body, status, err := c.do( 

"POST", 

path, 

doOptions{ 


data: struct { 
*Config 
HostConfig *HostConfig “json: 
rk 
opts.Config, 
opts.HostConfig, 
ty 
ty 


) 
if status == http.StatusNotFound { 


return nil, ErrNoSuchImage 


} 
if err != nil { 

return nil, err 
} 


var container Container 
err = json.Unmarshal(body, &container) 
if err != nil { 


return nil, err 


container.Name = opts.Name 


return &container, nil 


上 述 代码 其 实 就 是 通过 调用 标准 的 Docker RestAPI 来 实现 功能 的 ， 
我 们 进入 docker.Client 的 do 方法 里 可 以 看 到 更 多 详情 ， 例 如 输入 参数 转 
换 为 JSON 格 式 的 数据 、DockerAPI 版 本 检查 及 异常 处 理 等 逻辑 ， 最 有 趣 
的 是 : 在 dockerEndpoint 是 unix 套 接 字 的 情况 下 ， 会 先 建立 套 接 字 连 接 ， 
然后 在 这 个 连接 上 创建 HTTP 连 接 。 





至 此 ， 我 们 分 析 了 kubelet 创 建 和 同步 Pod 实 例 的 整个 流程 ， 简 单 总 
结 如 下 。 


。 汇 总: 先 将 多 个 Pod Source 上 过 来 的 PodUpdate 事 件 汇聚 到 一 个 总 的 
Channel 上 去 。 

。 初审 : 分 析 并 过 滤 掉 不 符合 本 节点 的 PodUpdate 事 件 ， 对 满足 条 件 
的 PodUpdate 则 生成 一 个 workUpdate 事 件 ， 交 给 podWorkers 处 理 。 

。 接待 : podWorkers 对 每 个 Pod 的 workUpdate 事 件 排队 ， 并 且 负 责 
新 Cache 中 的 Pod 状 态 ， 而 把 具体 的 任务 转 给 kubelet 去 处 理 
CSyncPod 方 法 ) 。 

。 AW: kubelet 对 符合 条 件 的 Pod 进 一 步 审 查 ， 例 如 检查 Pod 是 否 有 权 
在 本 节点 运行 ， 对 符合 审查 的 Pod 开 始 着 手 准 备 工 作 ， 包 括 目录 创 
建 、PV 创 建 、Image 获 取 、 处 理 Mirror Pod 问 题 等 ， 然 后 把 “皮球 ” 踢 
给 了 DockerManager。 

e yib: 任务 抵达 DockerManager 之 后 ，DockerManager 尽 心 尽责 地 分 
析 每 个 Pod 的 情况 ， 以 决定 这 个 Pod 究 竞 是 新 建 、 完 全 重启 还 是 部 分 
更 新 的 。 给 出 分 析 结 果 以 后 ， 剩 下 的 就 是 dockerClient 的 工作 了 。 














好 复杂 的 设计 ! 原来 非 业 务 流程 的 代码 理解 起 来 也 会 如 此 折磨 人 ， 
真心 不 知道 谷歌 当初 是 怎么 设计 和 实现 它 的 ， 目 测 国 内 P8 水 平 的 一 帮 大 
牛 们 天 天 加 班 到 9 点 钟 ， 也 难以 交付 这 样 的 Code。 





在 继续 下 面 的 分 析 之 前 ， 留 一 个 小 小 的 思考 给 聪明 的 读者 : Pod 
Source 上 发 来 的 Pod 删 除 的 事件 ， 是 在 哪里 处 理 的 ? 


接 下 来 我 们 继续 分 析 kubelet 进 程 的 另外 一 个 重要 功能 是 如 何 实现 
的 ， 即 定期 同步 Pod 状 态 信 息 到 API Server 上 。 先 来 看 看 Pod 状 态 的 数据 
结构 定义 : 


type PodStatus struct { 
Phase PodPhase “json: "phase, omitempty"~ 
Conditions []PodCondition ~json:"conditions, omitempty 
Message string ~json:"message, omitempty” 
Reason string ~json:"reason, omitempty"~ 
HostIP string ~json:"hostIP, omitempty" 
PodIP string ~json:"podIP, omitempty"~ 
StartTime *util.Time “json:"startTime, omitempty"- 
ContainerStatuses []ContainerStatus 
} 
// PodStatusResult is a wrapper for PodStatus returned b' 
type PodStatusResult struct { 
TypeMeta ~json:",inline"~ 
ObjectMeta ~json:"metadata, omitempty"~ 


Status PodStatus ~“json:"status,omitempty"- 


Pod 的 状态 (Phase) 有 5 种 : 运行 中 (PodRunning) 、 等 竺 中 
(PodPending) 、 正 常 终止 〈PodSucceeded) 、 异 常 停止 (PodFailed) 
及 未 知 状态 (PodUnknown) ， 最 后 一 种 状态 很 可 能 是 由 于 Pod 所 在 主机 
的 通信 问题 导致 的 。 从 上 面 的 定义 可 以 看 到 Pod 的 状态 同时 包括 它 里 面 
运行 的 Container 的 状态 ， 男 外 给 出 了 导致 当前 状态 的 原因 说 明 、Pod 的 
启动 时 间 等 信息 。PodStatusResult 则 是 Kubernete API Server 提 供 的 Pod 
Status API 接 口中 用 到 的 Wrapper 类 。 








通过 之 前 的 代码 研读 ， 我 们 发 现在 Kubernetes 中 大 量 使 用 了 Channel 
和 协 程 机 制 来 完成 数据 的 高 效 传递 和 处 理工 作 ， 在 kubelet 中 更 是 大 量 使 
用 了 这 一 机 制 ， 实 现 PodStatus 上 报 的 kubelet.statusManager 也 是 如 此 ， 它 
用 一 个 Map (podStatuses) 保存 了 当前 kubelet 中 所 有 Pod 实 例 的 当前 状 
态 ， 并 且 声 明了 一 个 Channel (podStatusChannel) 来 存放 Pod 状 态 同步 的 
更 新 请 求 CpodStatuses) ，Pod 在 本 地 实例 化 和 同步 的 过 程 中 会 引发 Pod 
状态 的 变化 ， 这 些 变 化 被 封装 为 podStatusSyncRequest 放 入 Channel 中 ， 
然后 被 异步 上 报到 API Server， 这 束 是 statusManager 的 运行 机 制 |。 








下 面 是 statusManager 的 SetPodStatus 方 法 ， 先 比较 缓存 的 状态 信息 ， 
如 果 状 态 发 生变 化 ， 则 触发 Pod 状 态 ， 生 成 podStatusSyncRequest 并 放 到 
队列 中 等 待 上 报 : 


func (s *statusManager) SetPodStatus(pod *api.Pod, statu: 
podFullName := kubecontainer .GetPodFullName (pod) 
s.podStatusesLock.Lock() 
defer s.podStatusesLock.Unlock() 
oldStatus, found := s.podStatuses[podFullName | 


// ensure that the start time does not change across 


if found && oldStatus.StartTime != nil { 
status.StartTime = oldStatus.StartTime 
} 
if status.StartTime.IsZero() { 
if pod.Status.StartTime.IsZero() { 
// the pod did not have a previously 
now := util.Now() 
status.StartTime = &now 
} else { 
status.StartTime = pod.Status.StartTui 


} 
} 
if !found || !isStatusEqual(&oldStatus, &status) { 
s.podStatuses[podFullName] = status 
s.podStatusChannel <- podStatusSyncRequest{po 
} else { 
glog.V(3).Infof("Ignoring same status for pod 
} 


下 面 是 在 Pod 实 例 化 的 过 程 中 ，kubelet 过 滤 掉 不 合适 本 节点 Pod 所 调 
用 的 上 述 方 法 的 代码 ， 类 似 的 调用 还 有 不 少 : 


func (kl *Kubelet) handleNotFittingPods(pods []*api.Pod) 
fitting, notFitting := checkHostPortConflicts(pods) 
for _, pod := range notFitting { 


reason := "HostPortConflict" 


kl.recorder.Eventf(pod, reason, "Cannot start 
k1l.statusManager .SetPodStatus(pod, api.PodSta 
Phase: api.PodFailed, 
Reason: reason, 


Message: "Pod cannot be started due ti 


} 
fitting, notFitting = kl.checkNodeSelectorMatching(fi 
for _, pod := range notFitting { 

reason := "NodeSelectorMismatching" 


kl.recorder.Eventf(pod, reason, "Cannot start 
k1.statusManager .SetPodStatus(pod, api.PodSta 
Phase: api.PodFailed, 
Reason: reason, 


Message: "Pod cannot be started due ti 


} 
fitting, notFitting = kl.checkCapacityExceeded(fittin 
for _, pod := range notFitting { 

reason := "CapacityExceeded" 


kl.recorder.Eventf(pod, reason, "Cannot start 
k1l.statusManager .SetPodStatus(pod, api.PodSta 
Phase: api.PodFailed, 
Reason: reason, 


Message: "Pod cannot be started due ti 
} 


return fitting 


最 后 ， 我 们 看 看 statusManager 是 怎么 把 Channel 的 数据 上 报到 API 
Server 上 的 ， 这 是 通过 Start 方 法 开局 一 个 协 程 无 限 循环 执行 syncBatch 方 
法 来 实现 的 ， 下 面 是 syncBatch 的 代码 : 


func (s *statusManager) syncBatch() error { 
syncRequest := <-s.podStatusChannel 
pod := syncRequest.pod 
podFullName := kubecontainer .GetPodFullName(pod) 


status := syncRequest.status 


var err error 
statusPod := &api.Pod{ 
ObjectMeta: pod.ObjectMeta, 
} 
statusPod, err = s.kubeClient.Pods(statusPod.Namespace) .| 
if err == nil { 
statusPod.Status = status 
_, err = s.kubeClient .Pods(pod.Namespace) .Upd 
// TODO: handle conflict as a retry, make tha 
if err == nil { 
glog.V(3).Infof("Status for pod %q up: 


return nil 


} 
go s.DeletePodStatus(podFullName ) 


return fmt.Errorf("error updating status for pod %q: : 


这 段 代 码 首 先 从 Channel 中 拉 取 一 个 syncRequest， 然 后 调用 API 
Server 接 口 来 获取 最 新 的 Pod 信 息 ， 如 果 成 功 ， 则 继续 调用 API Server 的 
UpdateStatus 接 口 更 新 Pod 状 态 ， 如 果 调 用 失败 则 删除 缓存 的 Pod 状 态 ， 
这 将 触及 kubelet 重 新 计算 Pod 状 态 并 再 次 尝试 更 新 。 





说 完了 Pod 流 程 ， 我 们 接 下 来 再 一 起 深入 分 析 Kubernetes 中 的 容器 探 
EF (Probe) 的 实现 机 制 。 我 们 知道 ， 容 器 正常 不 代表 里 面 运行 的 业务 
进程 能 正常 工作 ， 比 如 程序 还 没 初 始 化 好 ， 或 者 配置 文件 错误 导致 无 法 
正常 服务 ， 还 有 诸如 数据 库 连接 焊 满 导致 服务 异常 等 各 种 意外 情况 都 有 
可 能 发 生 ， 面 对 这 类 问题 ，cAdvisor 就 束手无策 了 ， 所 以 kubelet 引 入 了 
容器 探 针 技术 ， 容 器 探 针 按 照 作用 划分 为 以 下 两 种 。 





e ReadinessProbe: 用 来 探测 容器 中 的 用 户 服 务 进程 是 否 处 于 “可 服务 
状态 ”， 此 探 针 不 会 导致 容器 被 停止 或 重启 ， 而 是 导致 此 容器 上 的 
服务 被 标识 为 不 可 用 ，Kubernetes 不 会 发 送 请 求 到 不 可 用 的 容器 
上 ， 直 到 它们 可 用 为 止 。 

e LivenessProbe: 用 来 探测 容器 服务 是 否 处 于 “存活 状态 ”， 如 果 服 务 
当前 被 检测 为 Dead， 则 会 导致 容器 重启 事件 发 生 。 





下 面 是 探 针 相关 的 结构 定义 : 


type Probe struct { 
Handler 
InitialDelaySeconds int64 
TimeoutSeconds int64 


} 
type Handler struct { 


// One and only one of the following should be specif 
Exec *ExecAction 
HTTPGet *HTTPGetAction 


TCPSocket *TCPSocketAction 


从 上 面 的 定义 来 看 ， 探 针 可 以 通过 执行 容器 中 的 一 个 命令 、 发 起 一 
个 指向 容器 内 部 的 HITP Get 请 求 或 者 TCP 连 接 来 确定 容器 内 部 是 否 正常 
SLAPS 





上 面 的 代码 属于 API 包 中 的 一 部 分 ， 只 是 用 来 描述 和 存储 容器 上 的 
探 针 定义 ， 而 真正 的 探 针 实现 代码 则 位 于 pkg/kubelet/prober/prober.go 
里 ， 下 面 是 对 prober.Probe 的 定义 : 





type Prober interface { 


Probe(pod *api.Pod, status api.PodStatus, container a 


上 述 接口 方法 表示 对 一 个 Container 发 起 探测 并 返回 其 结果 。 
prober.Probe 的 实现 类 为 prober.prober， 其 结构 定义 如 下 : 


type prober struct { 
exec execprobe.ExecProber 
http httprobe.HTTPProber 
tcp tcprobe.TCPProber 
runner kubecontainer .ContainerCommandRunner 


readinessManager *kubecontainer .ReadinessManager 


refManager *kubecontainer .RefManager 


recorder record.EventRecorder 


其 中 exec、http、tcp 三 个 变量 分 别 对 应 三 种 探测 类 型 的 “ 探 涉 ”， 它 
们 已 经 各 自 实 现 了 相应 的 还 辑 。 比 如 下 面 这 段 代 码 是 HTTP 探头 的 核心 
逻辑 ， 即 连接 一 个 URL 发 起 GET 请 求 : 


func DoHTTPProbe(url *url.URL, client HTTPGetInterface) 

res, err := client.Get(url.String()) 

if err != nil { 
// Convert errors into failures to catch time 
return probe.Failure, err.Error(), nil 

} 

defer res.Body.Close() 

b, err := 1outil.ReadAll(res.Body) 

if err != nil { 
return probe.Failure, "", err 

} 

body := string(b) 

if res.StatusCode >= http.StatusOK && res.StatusCode 
glog.V(4).Infof("Probe succeeded for %s, Resp 
return probe.Success, body, nil 

} 

glog.V(4).Infof("Probe failed for %s, Response: %v", 


return probe.Failure, body, nil 


prober.prober 中 的 runner 则 是 exec 探 头 的 执行 器 ， 因 为 后 者 需要 在 被 
检测 的 容器 中 执行 一 个 cmd 命 令 : 


func (p *prober) newExecInContainer(pod *api.Pod, contai 
return execInContainer{func() ([]byte, error) { 


return p.runner.RunInContainer(containerID, cmd) 


}} 


实际 上 p.runner 束 是 之 前 我 们 分 析 过 的 DockerManager， 下 面 是 
RunInContainer 的 源码 : 


func (dm *DockerManager) RunInContainer(containerID stri 
// If native exec support does not exist in the loca 
useNativeExec, err := dm.nativeExecSupportExists() 
if err != nil { 
return nil, err 
} 
if !useNativeExec { 
glog.V(2).Infof("Using nsinit to run the command 
return dm.runInContainerUsingNsinit(containerID, 
} 
glog.V(2).Infof("Using docker native exec to run cmd 
createOpts := docker.CreateExecOptions{ 
Container: containerID, 
Cmd: cmd, 


AttachStdin: false, 


AttachStdout: true, 
AttachStderr: true, 
Tty: false, 
} 
execObj, err := dm.client.CreateExec(createOpts) 
if err != nil { 
return nil, fmt.Errorf("failed to run in contain 
} 
var buf bytes.Buffer 
startOpts := docker.StartExecOptions{ 
Detach: false, 
Tty: false, 
OutputStream: &buf, 
ErrorStream: &buf, 
RawTerminal: false, 
} 
err = dm.client.StartExec(execObj.ID, startOpts) 
if err != nil { 
glog.V(2).Infof("StartExec With error: %v", err) 
return nil, err 
} 
ticker := time.NewTicker(2 * time.Second) 


defer ticker.Stop() 


for { 
inspect, err2 := dm.client.InspectExec(execObj.I 
if err2 != nil { 


glog.V(2).Infof("InspectExec %s failed with 


return buf.Bytes(), err2 
} 
if !inspect.Running { 
if inspect.ExitCode != 0 { 
glog.V(2).Infof("InspectExec %s exit wit 


err = &dockerExitError{inspect} 


break 


<-ticker.C 


return buf.Bytes(), err 


Docker 自 1.3 版 本 开始 文 持 使 用 Exec 指 令 〈 以 及 API 调 用 ) 在 容器 内 
执行 一 个 命令 ， 我 们 看 看 上 述 过 程 中 使 用 的 dm.client.CreateExec 方 法 是 
如 何 实现 的 : 


func (c *Client) CreateExec(opts CreateExecOptions) (*Ex: 
path := fmt.Sprintf("/containers/%s/exec", opts.Conta. 
body, status, err := c.do("POST", path, doOptions{dati 
if status == http.StatusNotFound { 
return nil, &NoSuchContainer{ID: opts.Contain 
} 
if err != nil { 


return nil, err 


} 
Var exec Exec 
err = json.Unmarshal(body, &exec) 
if err != nil { 
return nil, err 


return &exec, nil 


我 们 看 到 ， 这 是 标准 的 Docker API 的 调用 方式 ， 跟 之 前 看 到 的 创建 
容器 的 调用 代码 很 相似 。 现 在 我 们 再 回头 看 看 prober.prober 是 怎么 执行 
ReadinessProbe/LivenessProbe 的 检测 逻辑 的 : 


func (pb *prober) Probe(pod *api.Pod, status api.PodStat 
pb.probeReadiness(pod, status, container, containerID 


return pb.probeLiveness(pod, status, container, conta 


这 段 代 码 先 调用 容器 的 ReadinessProbe 进 行 检 测 ， 并 且 在 
readinessManager 组 件 中 记录 容器 的 Readiness 状 态 ， 随 后 调用 容器 的 
LivenessProbe 进 行 检测 ， 并 返回 容器 的 状态 ， 在 检测 过 程 中 如 果 发 现状 
态 为 失败 或 者 异常 状态 ， 则 会 连续 检测 3 次 : 





func (pb *prober) runProbeWithRetries(p *api.Probe, pod 
var err error 
var result probe.Result 


var output string 


for i := 0; i < retries; i++ { 
result, output, err = pb.runProbe(p, pod, sta 
if result == probe.Success { 


return probe.Success, output, nil 


return result, output, err 








比较 意外 的 是 prober.prober 探 针 检测 容器 状态 的 方法 目前 只 在 一 处 
被 调用 到 ， 位 于 方法 DockerManager.computePodContainerChanges 里 : 


result, err := dm.prober.Probe(pod, podStatus, container 
if err != nil { 

// TODO(vmarmol): examine this logic. 

glog.V(2).Infof("probe no-error: %q", 


containersToKeep[containerID] = index 


continue 

} 

if result == probe.Success { 
glog.V(4).Infof("probe success: %q", | 
containersToKeep[containerID] = index 
continue 

} 


glog.Infof("pod %q container %q is unhealthy 


containersToStart[index] = empty{} 





只 有 没有 发 生 任何 变化 的 Pod 才 会 执行 一 次 探 针 检测 ， 寿 检测 状态 
为 失败 ， 则 会 导致 重启 事件 发 生 。 


本 节 最 后 ， 我 们 再 来 简单 分 析 下 kubelet 中 的 Kubelet Server 的 实现 机 
制 ， 下 面 是 kubelet 进 程 启动 过 程 中 启动 Kubelet Server 的 源码 入 口 : 


// start the kubelet server 
if kc.EnableServer { 
go util.Forever(func() { 
k.ListenAndServe(net.IP(kc.Address), kc.Port 
}, 9) 


在 上 述 代 码 调用 的 过 程 中 ， 创 建 了 一 个 类 型 为 kubelet.Server 的 
HTTP Server 并 在 本 地 监听 : 


handler := NewServer(host, enableDebuggingHandlers ) 


s := &http.Server{ 


Addr: net.JoinHostPort(address.Stri 
Handler: &handler, 

ReadTimeout : 5 * time.Minute, 
WriteTimeout: 5 * time.Minute, 


MaxHeaderBytes: 1 << 20, 
} 
if tlsOptions != nil { 
s.TLSConfig = tlsOptions.Config 


glog.Fatal(s.ListenAndServeTLS(tlsOptions.Cer 


} else { 


glog.Fatal(s.ListenAndServe() ) 


在 kubelet.Server 的 构造 函数 里 加 载 如 下 HTTP Handler: 


func (s *Server) InstallDefaultHandlers() { 
healthz.InstallHandler(s.mux, 
healthz.PingHealthz, 
healthz.NamedCheck("docker", s.dockerHealthCh 
healthz.NamedCheck("hostname", s.hostnameHeal 
healthz.NamedCheck("syncloop", s.syncLoopHeal 
) 
s.mux.HandleFunc("/pods", s.handlePods ) 
s.mux.HandleFunc("/stats/", s.handleStats) 


s.mux.HandleFunc("/spec/", s.handleSpec ) 








上 述 Handler 分 为 两 组 : 首先 是 健康 检查 ， 包 括 kubelet 进 程 自身 的 心 
跳 检 查 、Docker 进 程 的 健康 检查 、kubelet 所 在 主机 名 检测 、Pod 同 步 的 
健康 检查 等 ， 然 后 是 获取 当前 节点 上 运行 期 信息 的 接口 ， 例 如 获取 当前 
节点 上 的 Pod 列 表 、 统 计 信息 等 。 下 面 是 hostnameHealthCheck 的 实现 逻 
辑 ， 它 检查 Pod 两 次 同步 之 间 的 时 延 ， 而 这 个 时 延 则 在 之 前 提 到 的 
kubelet 的 syncLoopIteration 方 法 中 进行 更 新 : 








func (s *Server) syncLoopHealthCheck(req *http.Request ) 


duration := s.host.ResyncInterval() * 2 


minDuration := time.Minute * 5 

if duration < minDuration { 
duration = minDuration 

} 

enterLoopTime := s.host.LatestLoopEntryTime() 

if !enterLoopTime.IsZero() && time.Now().After(enterL 
return fmt.Errorf("Sync Loop took longer than 


} 


return nil 





handlePods 的 API 则 从 kubelet 中 获取 当前 “ 绑 定 ?到 本 节点 的 所 有 Pod 
的 信 AR 回 : 


func (s *Server) handlePods(w http.ResponseWriter, req * 
pods := s.host.GetPods() 
data, err := encodePods(pods) 
if err != nil { 
s.error(w, err) 
return 
} 
w.Header().Add("Content-type", "application/json") 


w.Write(data) 


如 果 kubelet 运 行 在 Debug 模 式 ， 则 加 载 更 多 的 HITP Handler: 


Jo 


func (s *Server) InstallDebuggingHandlers() { 


S. 


S. 


S. 


S. 


S. 


S. 


mux 


mux 


mux 


mux 


mux 


mux 


.HandleFunc('"/run/", s.handleRun) 
.HandleFunc("/exec/", s.handleExec) 


»HandleFunc('"/portForward/", s.handlePortForwar 


.HandleFunc("/logs/", s.handleLogs) 
.HandleFunc("/containerLogs/", s.handleContaine 


.Handle("/metrics", prometheus.Handler() ) 


// The /runningpods endpoint is used for testing onl 


s.mux.HandleFunc("/runningpods", s.handleRunningPods 


s.mux.HandleFunc("/debug/pprof/", pprof.Index) 


s.mux.HandleFunc("/debug/pprof/profile", pprof.Profi 


s.mux.HandleFunc("/debug/pprof/symbol", pprof.Symbol 


这 些 HTTPHandler 的 实现 并 不 复杂 ， 所 以 在 这 里 就 不 再 一 一 介绍 


6.5.3 ”设计 总 结 





在 研读 kubelet 源 码 的 过 程 中 ， 你 经 常会 有 “ 山 穷 水 尽 疑 无 路 ， 柳 上 暗 
化 明 又 一 村 ”的 感觉 ， 是 因为 在 它 的 设计 中 大 量 运 用 了 Channel 这 种 异步 
消息 机 制 ， 加 之 为 了 测试 的 方便 ， 又 将 很 多 重要 的 处 理 函 数 做 成 接口 
类 ， 只 有 找到 并 分 析 这 些 接口 的 具体 实现 类 ， 才 能 明白 整个 流程 。 这 对 
于 习惯 了 面向 对 象 语言 的 程序 员 而 言 ， 有 一 种 一 夜 回 到 解放 前 的 感觉 。 








因为 kubelet 的 功能 比较 多 ， 所 以 我 们 在 此 仅 以 Pod 同 步 的 主流 程 为 
例 ， 进 行 一 个 设计 总 结 ， 图 6.8 是 kubelet 主 流程 相关 的 设计 示意 图 ， 为 了 
更 加 清晰 地 展示 整个 流程 ， 我 们 特意 将 kubelet Kernel. Docker System 与 
其 他 部 分 分 离开 来 ， 并 且 省 略 了 部 分 非 核心 对 象 和 数据 结构 。 


首先 ，config.PodConfig 创 建 一 个 或 多 个 Pod Source， 在 默认 情况 下 
创建 的 是 API source， 它 并 没有 创建 新 的 数据 结构 ， 而 是 使 用 之 前 介绍 
的 cache.Reflector 结 合 cache.UndeltaStore， 从 Kubernetes API Server 上 拉 
取 Pod 数 据 放 入 内 部 的 Channel 上， 而 内 部 的 Channel 收 到 Pod 数 据 后 会 调 
用 podStorage 的 Merge 方 法 实现 多 个 Channel 数 据 的 合并 ， 产 生 
kubelet.PodUpdate 消 息 并 写 入 PodConfig 的 汇总 Channel 上， 随后 
PodUpdate 消 息 进 入 kubelet Kernel 中 进行 下 一 步 处 理 。 


kubelet.kubelet 的 syncLoop 方 法 监听 PodConfig 的 汇总 Channel， 过 滤 
挥 不 合适 的 PodUpdate 并 把 符合 条 件 的 放 入 SyncPods 方 法 中 ， 最 终 为 
个 符合 条 件 的 Pod 产 生 一 个 kubelet.workUpdate 事 件 并 放 入 podWorkers 的 
内 部 工作 队列 上 ， 随 后 调用 podWorkers 的 managePodLoop 方 法 进行 处 





理 。podWorkers 在 处 理 流程 中 调用 了 DockerManager 的 SyncPod 方 法 ， 由 
此 DockerManager 接 班 ， 在 进行 了 必要 的 Pod 周 边 操 作 后 ， 对 于 需要 重 局 
或 者 更 新 的 容器 ，DockerManager 则 交 给 docker.Client 对 象 去 执行 具体 的 
动作 ， 后 者 通过 调用 Dockers Engine 的 API Service 来 实现 具体 功能 。 


在 Pod 同 步 的 过 程 中 会 产生 Pod 状 态 的 变更 和 同步 问题 ， 这 些 是 交 由 
kubelet.statusManager 实 现 的 ， 它 在 内 部 也 采用 了 Channel 的 设计 方式 。 


| config. PodConfig | Create 















































Docker System 





图 6.8 kubelet 主 流程 相关 的 设计 示意 图 


6.6 ”kube-proxy 进 程 源码 分 析 


kube-proxy 是 运行 在 Minion 节 点 上 的 另外 一 个 重要 的 守护 进程 ， 你 
可 以 把 它 当 作 一 个 HAProxy， 它 充当 了 Kubernetes 中 Service 的 负载 均衡 
器 和 服务 代理 的 角色 。 下 面 我 们 分 别 对 其 启动 过 程 、 关 键 代 码 分 析 及 设 
计 总 络 等 方面 进行 深入 分 析 和 讲解 。 


6.6.1 ”进程 启动 过 程 


kube-proxy 进 程 的 入 口 类 源码 位 置 如 下 : 


github/com/GoogleCloudPlatform/kubernetes/cmd/kube-proxy 


入 口 main() 函数 的 逻辑 如 下 : 


func main() { 
runtime .GOMAXPROCS( runtime .NumCPU( ) ) 
s := app.NewProxyServer() 


s.AddFlags(pflag.CommandLine ) 


util.InitFlags() 
util.InitLogs() 


defer util.FlushLogs() 
verflag.PrintAndExitIfRequested() 
if err := s.Run(pflag.CommandLine.Args()); err != nil 


fmt.Fprintf(os.Stderr, "%v\n", err) 


os.Exit(1) 


上 述 代 码 构造 了 一 个 ProxyServer， 然 后 调用 它 的 Run 方 法 启动 运 
行 。 首 先 我 们 看 看 NewProxyServer 的 代码 : 


func NewProxyServer() *ProxyServer { 
return &ProxyServer{ 
BindAddress: util.IP(net.ParseIP("0.0.0.0 
HealthzPort: 10249, 
HealthzBindAddress: util.IP(net.ParseIP("127.0.0 
OOMScoreAdj: -899, 


ResourceContainer: '"/kube-proxy", 


在 上 述 代码 中 ，ProxyServer 绑 定 本 地 所 有 IP (0.0.0.0) 对 外 提供 代 
理 服务 ， 而 提供 健康 检查 的 HITP Server 则 默认 绑 定 本 地 的 回环 卫 ， 说 
明 后 者 仅 用 于 在 本 节点 上 访问 ， 如 果 需 要 开发 管理 系统 进行 远程 管理 ， 
则 可 以 设置 参数 healthz-bind-address 为 0.0.0.0 来 达到 目的 。 另 外 ， 从 代码 
中 看 ，ProxyServer 还 有 一 个 重要 属性 可 以 调整 : PortRange《〈 对 应 命令 
行 参数 为 proxy-port-range) ， 它 用 来 限定 ProxyServer 使 用 哪些 本 地 端口 
作为 代理 端口 ， 默 认 是 随机 选择 。 


ProxyServer 的 Run 方 法 流程 如 下 。 


。 设置 本 进程 的 OOM 参 数 OOMScoreAdj ， 保 证 系统 OOM 时 ，kube- 
proxy 不 会 首先 被 系统 删除 ， 这 是 因为 kube-proxy 与 kubeletj 进 程 一 
样 ， 比 节点 上 的 Pod 进 程 更 重要 。 

e 让 自己 的 进程 运行 在 指定 的 Linux Container 中 ， 这 个 Container 的 名 
字 来 自 ProxyServer.ResourceContainer， 如 上 所 述 ， 默 认为 /kube- 





proxy, 比较 重 要 的 一 点 是 这 个 Container 具 备 所 有 设备 的 访问 权 。 

e 创建 ServiceConfig 与 EndpointsConfig， 它 们 与 之 前 kubelet 中 的 
PodConfig 的 作用 和 实现 机 制 有 点 像 ， 分 别 负责 监听 和 拉 取 API 
Server 上 Service 与 Service Endpoints 的 信息 ， 并 通知 给 注册 到 它们 上 
的 Listener 接 口 进 行 处 理 。 

。 创建 一 个 round-robin 轮 询 机 制 的 load balancer (LoadBalancerRR) ， 
它 用 来 实现 Service 的 负载 均衡 转发 馆 辑 ， 它 也 是 前 面 创建 的 
EndpointsConfig 的 一 个 Listener。 

e 创建 一 个 Proxier， 它 负责 建 并 和 维护 Service 的 本 地 代理 Socket， 它 
也 是 前 面 创建 的 ServiceConfig 的 一 个 Listener。 

。 创建 一 个 config.SourceAPI， 并 启动 两 个 协 程 ， 通 过 Kubernetes 
Client 来 拉 取 Kubernetes API Server 上 的 Service 与 Endpoint 数 据 ， 然 
后 分 别 写 入 之 前 定义 的 ServiceConfig 与 EndpointsConfig 的 Channel 
上 ， 从 而 触发 整个 流程 的 驱动 。 

。 本 地 绑 定 健康 检查 的 HITP Server 提 供 服务 。 

e 进入 Proxier 的 SyncLoop 方 法 里 ， 该 方法 周期 性 地 检查 Iptables 是 否 
设置 正常 、 服 务 的 Portal 是 否 正常 开 司 ， 以 及 清除 load balancer 上 的 
过 期 会 话 。 


从 启动 流程 看 ，kube-proxy 进 程 的 参数 比较 少 ， 它 所 做 的 事情 也 是 
比较 单一 的 ， 没 有 kubelet 进 程 那么 复杂 ， 在 下 一 节 我 们 会 深入 分 析 其 关 
键 代码 。 


6.6.2 关键 代码 分 析 


从 上 一 市 kube-proxy 的 启动 流程 来 看 ， 它 跟 kubelet 有 相似 的 地 方 ， 
即 都 会 从 Kubernetes API Server 拉 取 相 关 的 资源 数据 并 在 本 地 市 点 上 完 
成 “深加工 >”， 其 拉 取 资源 的 做 法 ， 第 一 眼看 上 去 与 kubelet 相 似 ， 但 实际 
上 有 稍微 不 同 的 实现 思路 ， 这 说 明 作 者 另 有 其 人 。 


由 于 ServiceConfig 与 EndpointsConfig 实 现 机 制 是 完全 一 样 的 ， 只 不 
过 拉 取 的 资源 不 同 ， 所 以 我 们 这 里 仅 对 前 者 做 深入 分 析 。 首 先 从 
ServiceConfig 结 构 体 开始 : 


type ServiceConfig struct { 
mux *config.Mux 
bcaster *config.Broadcaster 


store *serviceStore 


ServiceConfig 也 使 用 了 mux (config. Mux) ， 它 是 一 个 多 Channel 的 
多 路 合并 器 ， 之 前 kubelet 的 PodConfig 也 用 到 了 它 。 下 面 是 ServiceConfig 
的 构造 函数 : 





func NewServiceConfig() *ServiceConfig { 
updates := make(chan struct{}) 
store := &serviceStore{updates: updates, services: ma 


mux := config.NewMux(store) 


bcaster := config.NewBroadcaster() 
go watchForUpdates(bcaster, store, updates) 


return &ServiceConfig{mux, bcaster, store} 


从 上 述 代码 来 看 ，store 是 serviceStore 的 一 个 实例 。 它 作为 
config.Mux 的 Merge 接 口 的 实现 ， 负 责 处 理 config.Mux 的 Channel 上 收 到 
的 ServiceUpdate 消 息 并 更 新 store 的 内 部 变量 services， 后 者 是 一 个 Map， 
存放 了 最 新 同步 到 本 地 的 api.Service 资 源 ， 是 Service 的 全 量 数据 。 下 面 
是 Merge 方 法 的 逻辑 : 





func (s *serviceStore) Merge(source string, change inter’ 
s.serviceLock.Lock( ) 
services := s.services[source ] 
if services == nil { 
services = make(map[types.NamespacedName Jap1.: 
} 
update := change. (ServiceUpdate) 
Switch update.Op { 
case ADD: 
glog.V(4).Infof("Adding new service from souri 
for _, value := range update.Services { 
name := types.NamespacedName{value.Na 
services[name] = value 
} 


case REMOVE: 


glog.V(4).Infof("Removing a service %+v", updi 


for _, value := range update.Services { 
name := types.NamespacedName{value.Na 


delete(services, name) 


} 


case SET: 


default: 


} 


glog.V(4).Infof("Setting services %+v", updat 
// Clear the old map entries by just creating 
services = make(map[types.NamespacedName Jap1.: 
for _, value := range update.Services { 

name := types.NamespacedName{value.Na 


services[name] = value 


glog.V(4).Infof("Received invalid update type 


s.services[source] = services 


s.serviceLock.Unlock( ) 


if s.updates != nil { 


} 


s.updates <- struct{}{} 


return nil 


serviceStore 同 时 是 config.Accessor 接 口 的 一 个 实现 ，MergedState 接 
口 方法 返回 之 前 Merge 最 新 的 Service 全 量 数 据 。 


func (s *serviceStore) MergedState() interface{} { 


s.serviceLock.RLock() 


defer s.serviceLock.RUnlock( ) 


services := make([]api.Service, 0) 
for _, sourceServices := range s.services { 
for _, value := range sourceServices { 


services = append(services, value) 


} 


return services 


上 述 方 法 在 哪里 被 用 到 了 呢 ? 就 在 之 前 提 到 的 NewServiceConfig 方 
JER: 


go watchForUpdates(bcaster, store, updates) 


一 个 协 程 监听 serviceStore 的 updates (Channel) ， 在 收 到 事件 以 后 
就 调用 上 述 MergedState 方 法 ， 将 当前 最 新 的 Service 数 组 通知 注册 到 
bcaster 上 的 所 有 Listener 进 行 处 理 。 下 面 分 别 给 出 了 watchForUpdates 及 
Broadcaster 的 Notify 方 法 的 源码 : 


func watchForUpdates(bcaster *config.Broadcaster, access 
for true { 
<-updates 


bcaster.Notify(accessor.MergedState() ) 


func (b *Broadcaster) Notify(instance interface{}) { 
b.listenerLock.RLock( ) 
listeners := b.listeners 
b.listenerLock.RUnlock() 
for _, listener := range listeners { 


listener .OnUpdate(instance) 


上 述 逻 辑 的 精巧 设计 之 处 在 于 ， 当 ServiceConfig 完 成 Merge 调 用 
后 ， 为 了 及 时 通知 Listener 进 行 处 理 ， 束 产生 一 个 “ 空 事 件 ”* 并 写 入 
updates 这 个 Channel 中 ， 另 外 监听 此 Channel 的 协 程 就 及 时 得 到 通知 ， 触 
发 Listener 的 回调 动作 。ServiceConfig 这 里 注册 的 Listener 是 proxy.Proxier 
对 象 ， 我 们 以 后 会 继续 分 析 它 的 回调 函数 OnUpdate 是 如 何 使 用 Service 数 
据 的 。 


接 下 来 ， 我 们 看 看 ServiceUpdate 事 件 是 怎么 生成 并 传递 到 
ServiceConfig 的 Channel 上 的 。 在 kube-proxy 局 动 流程 中 有 调用 
config.NewSourceAPI 函 数 ， 其 内 部 生成 了 一 个 servicesReflector 对 象 : 


type servicesReflector struct { 
watcher ServicesWatcher 
services chan<- ServiceUpdate 
resourceVersion string 
waitDuration time.Duration 


reconnectDuration time.Duration 


其 中 services 这 个 Channel 是 用 来 写 入 ServiceUpdate 事 件 的 ， 它 是 
ServiceConfig 的 Channel (source string) 方法 所 创建 并 返回 的 Channel， 
它 写 入 数据 后 就 会 被 一 个 协 程 立即 转发 到 ServiceConfig 的 Channel] 里 。 下 
面 这 上 段 代 码 完整 地 揭示 了 上 述 逻 辑 : 


func (c *ServiceConfig) Channel(source string) chan Serv 

ch := c.mux.Channel(source) 
serviceCh := make(chan ServiceUpdate) 
go func() { 

for update := range serviceCh { 

ch <- update 
} 
close(ch) 


}() 


return serviceCh 


servicesReflector 中 的 watcher 用 来 从 API Server 上 拉 取 Service 数 据 ， 
它 是 client.Services (api.NamespaceAll) 返回 的 client.ServiceInterface 实 
例 对 象 的 一 个 引用 ， 属 于 标准 的 Kubernetes client 包 。 在 
config.NewSourceAPI 的 方法 里 ， 启 动 了 一 个 协 程 周期 性 地 调用 watcher 
的 list 与 Watch 方法 获取 数据 ， 然 后 转换 成 ServiceUpdate 事 件 ， 写 入 
Channel 中 。 下 面 是 关键 源码 : 


func (s *servicesReflector) run(resourceVersion *string) 
if len(*resourceVersion) == © { 


services, err := s.watcher.List(labels.Everyt 


if err != nil { 
glog.Errorf("Unable to load services: 
// TODO: reconcile with pkg/client/ca 
time.Sleep(wait.Jitter(s.waitDuration 
return 

} 

*resourceVersion = services.ResourceVersion 

// TODO: replace with code to update the 


s.services <- ServiceUpdate{Op: SET, Services 


} 
watcher, err := s.watcher.Watch(labels.Everything(), © 
if err != nil { 
glog.Errorf("Unable to watch for services cha 
if !client.IsTimeout(err) { 
// Reset so that we do a fresh get re 
*resourceVersion = "" 
} 
time.Sleep(wait.Jitter(s.waitDuration, 0.0)) 
return 
} 


defer watcher.Stop() 
ch := watcher .ResultChan() 


s.watchHandler(resourceVersion, ch, s.services) 


在 上 面 的 代码 中 ， 初 始 时 资源 版 本 变量 resourceVersion 为 空 ， 于 是 
会 执行 Service 的 全 量 拉 取 动 作 Cwatcher.List) ， 之 后 Watch 资源 会 开始 


发 生变 化 Cwatcher.Watch) 并 将 Watch 的 结果 《一 个 Channel 保 持 了 
Service 的 变动 数据 ) 也 转换 为 对 应 的 ServiceUpdate 事 件 并 写 入 Channel 
中 。 男 外 ， 当 拉 取 数据 的 调用 发 生 异 常 时 ，resourceVersion 恢 复 为 空 ， 
导致 重新 进行 全 量 资源 的 拉 取 动作 。 这 种 自修 复 能 力 的 编程 设计 足以 见 
证 谷歌 大 神 们 的 深厚 编程 功力 ;， 男 外 ， 笔 者 认为 kube-proxy 这 里 的 
ServiceConfig 的 设计 实现 思路 和 代码 要 比 kubelet 中 的 好 一 点 ， 虽 然 两 个 
作者 都 是 顶尖 高 





接 下 来 才 开 始 进入 本 节 的 重点 ， 即 服务 代理 的 实现 机 制 分 析 。 首 
先 ， 我 们 从 代码 中 的 load balance 组 件 说 起 。 下 面 是 kube-proxy 中 定义 的 
LoadBalancer 接 口 : 


type LoadBalancer interface { 
NextEndpoint(service ServicePortName, srcAddr net.Add 
NewService(service ServicePortName, sessionAffinityTy 
CleanupStaleStickySessions(service ServicePortName ) 


} 


LoadBalancer 有 3 个 接口 ， 其 中 NextEndpoint 方 法 用 于 给 访问 指定 
Service 的 新 客户 端 请 求 分 配 一 个 可 用 的 Endpoint 地 址 ， NewService 用 来 
添加 一 个 新 服务 到 负载 均衡 器 上 ; CleanupStaleStickySessions 则 用 来 清 
理 过 期 的 Session 会 话 。 目 前 kube-proxy 只 实现 了 一 个 基于 round-robin 算 
法 的 负载 均衡 器 ， 它 就 是 proxy.LoadBalancerRR 组 件 。 





LoadBalancerRR 采 用 了 affinityState 这 个 结构 体 来 保存 当前 客户 端的 
会 话 信 息 ， 然 后 在 affinityPolicy 里 用 一 个 Map 来 记录 《属于 某 个 Service 
的 ) 所 有 活动 的 客户 端 会 话 ， 这 是 它 实 现 Session 杀 和 性 的 负载 均衡 调度 
的 基础 。 











type affinityState struct { 
clientIP string 
//clientProtocol api.Protocol //not yet used 
//sessionCookie string //not yet used 
endpoint string 
lastUsed time.Time 
} 
type affinityPolicy struct { 
affinityType api.ServiceAffinity 
affinityMap map[string]*affinityState // map client 


ttlMinutes int 


balancerState 用 来 记录 一 个 Service 的 所 有 Endpoint 〈 数 组 ) 、 当 前 所 
使 用 的 Endpoint 的 index， 以 及 对 应 的 所 有 活动 的 客户 端 会 话 
CaffinityPolicy) 。 其 定义 如 下 : 





type balancerState struct { 
endpoints []string // a list of "ip:port" style strin 
index int // current index into endpoints 


affinity affinityPolicy 


有 了 上 面 的 认识 ， 再 看 LoadBalancerRR 的 构造 函数 就 简单 多 了 ， 它 
内 部 用 一 个 map 记 录 每 个 服务 的 balancerState 状 态 ， 当 然 初 始 化 时 还 是 衬 
的 : 


func NewLoadBalancerRR() *LoadBalancerRR { 
return &LoadBalancerRR{ 


services: map[ServicePortName]*balancerState{ 


LoadBalancerRR 的 NewService 方 法 代码 很 简单 ， 就 是 在 它 的 services 
里 增加 一 个 记录 项 ， 用 户 端 的 会 话 超时 时 间 ttlMinutes 默 认为 3 小 时 ， 下 
面 是 相关 源码 : 


func (lb *LoadBalancerRR) NewService(svcPort ServicePort 
1b.lock.Lock() 
defer 1b.lock.Unlock() 
1lb.newServiceInternal(svcPort, affinityType, ttlMinut: 
return nil 

} 

func (lb *LoadBalancerRR) newServiceInternal(svcPort Ser' 
if ttlMinutes == 0 { 


ttlMinutes = 180 


} 

if _, exists := lb.services[svcPort]; !exists { 
lb.services[svcPort] = &balancerState{affinit' 
glog.V(4).Infof("LoadBalancerRR service %q di 

} else if affinityType != "" { 
lb.services[svcPort].affinity.affinityType = i 

} 


return 1b.services[svcPort] 


我 们 在 前 面 提 到 过 ServiceConfig 同 步 并 监听 API Server 上 的 
api.Service 的 数据 变化 ， 然 后 调用 Listener (proxy.Proxier 是 ServiceConfig 
唯一 注册 的 Listener) 的 OnUpdate 接 口 完 成 通知 。 而 上 述 NewService 就 
是 在 proxy.Proxier 的 OnUpdate 方 法 里 被 调用 的 ， 从 而 实现 了 Service 上 自动 
添加 到 LoadBalancer 的 机 制 |。 


我 们 再 来 看 LoadBalancerRR 的 NextEndpoint 方 法 ， 它 实现 了 经 典 的 
round-robin 负 载 均 衡 算 法 。NextEndpoint 方 法 首先 判断 当前 服务 是 否 
保持 会 话 〈sessionAffinity) 的 要 求 ， 如 果 有 ， 则 看 当前 请 求 是 否 有 连接 
可 用 : 








if sessionAffinityEnabled { 

// Caution: don't shadow ipaddr 

var err error 

ipaddr, _, err = net.SplitHostPort(srcAddr.St 

if err != nil { 
return "", fmt.Errorf("malformed sour 

} 

sessionAffinity, exists := state.affinity.aff 

if exists && int(time.Now().Sub(sessionAffini 
// Affinity wins. 
endpoint := sessionAffinity.endpoint 
sessionAffinity.lastUsed = time.Now() 
glog.V(4).Infof("NextEndpoint for ser.' 


return endpoint, nil 


如 果 服 务 无 须 会话 保 持 、 新 建 会 话 及 会 话 过 期 ， 则 采用 round-robin 
算法 得 到 下 一 个 可 用 的 服务 端口 ， 如 果 服 务 有 会 话 保持 需求 ， 则 保存 当 
前 的 会 话 状态 : 





// Take the next endpoint. 
endpoint := state.endpoints[state. index] 
state.index = (state.index + 1) % len(state.endpoints 
if sessionAffinityEnabled { 
var affinity *affinityState 
affinity = state.affinity.affinityMap[ipaddr | 
if affinity == nil { 
affinity = new(affinityState) //&saffi 
state.affinity.affinityMap[ipaddr] = 
} 
affinity.lastUsed = time.Now() 
affinity.endpoint = endpoint 


affinity.clientIP 


ipaddr 
glog.V(4).Infof("Updated affinity key %s: %+v 
} 


return endpoint, nil 


接 下 来 我 们 看 看 Service 的 Endpoint 信 息 是 如 何 谎 加 到 
LoadBalancerRR 上 的 ? 答案 很 简单 ， 类 似 之 前 我 们 分 析 过 的 
ServiceConfig。kube-proxy 也 设计 了 一 个 EndpointsConfig 来 拉 取 和 监听 


API Server 上 的 服务 的 Endpoint 信 息 ， 并 调用 LoadBalancerRR 的 OnUpdate 
接口 完成 通知 ， 在 这 个 方法 里 ，LoadBalancerRR 完 成 了 服务 访问 端口 的 
添加 和 同步 逻辑 。 


我 们 先 来 看 看 api.Endpoints 的 定义 : 


type EndpointAddress struct { 
IP string 
TargetRef *ObjectReference 

} 

type EndpointPort struct { 
Name string 
Port int 
Protocol Protocol 

} 

type EndpointSubset struct { 
Addresses []EndpointAddress 
Ports []EndpointPort 

} 

type Endpoints struct { 
TypeMeta *json:",inline"” 
ObjectMeta ~json:"metadata, omitempty"- 


Subsets []EndpointSubset 


一 个 EndpointAddress 与 EndpointPort 对 象 可 以 组 成 一 个 服务 访问 地 
址 ， 而 在 EndpointSubset 对 象 里 则 定义 了 两 个 单独 的 EndpointAddress 与 


EndpointPort 数 组 而 不 是 “服务 访问 地 址 ”的 一 个 列表 。 初 看 这 样 的 定义 
你 可 能 会 觉得 很 奇怪 ， 为 什么 没有 设计 一 个 Endpoint 结 构 ? 这 里 的 深层 
次 原因 在 于 ，Service 的 Endpoint 信 息 来 源 于 两 个 独立 的 实体 : Pod 与 
Service， 前 者 负责 提供 IP 地 址 即 EndpointAddress， 而 后 者 负责 提供 Port 
即 EndpointPort。 由 于 在 一 个 Pod 上 可 以 运行 多 个 Service， 而 一 个 Service 
也 通常 跨越 多 个 Pod， 于 是 束 产 生 了 一 个 “ 笛 卡 尔 乘 积 ” 的 Endpoint 列 表 ， 
这 就 是 EndpointSubset 的 设计 灵感 。 


举例 说 明 ， 对 于 如 下 表示 的 EndpointSubset: 


Addresses: [{"ip": "10.10.1.1"}, {"ip": "10.10.2.2" 


Ports: [{"name": "a", "port": 8675}, {"name": "b", 


会 产生 如 下 Endpoint 列 表 : 


a: [ 10.10.1.1:8675, 10.10.2.2:8675 ], 
b: [ 10.10.1.1:309, 10.10.2.2:309 ] 


LoadBalancerRR 的 OnUpdate 方 法 里 循环 对 每 个 api.Endpoints 进 行 处 
理 ， 先 把 它 转 化 为 一 个 Map，Map 的 Key 是 EndpointPort 的 Name 属 性 《〈 代 
表 一 个 Service 的 访问 端口 ) ;而 Value 则 是 hostPortPair 的 一 个 数组 ， 
hostPortPair 其 实 就 是 之 前 缺失 的 Endpoint 结 构 体 ， 包 括 一 个 了 下 地 址 与 端 
口 属性 ， 即 茶 个 服务 在 一 个 Pod 上 的 对 应 访问 端口 。 





portsToEndpoints := map[string][ ]hostPortPair{} 


for 1 := range svcEndpoints.Subsets { 


ss := &svcEndpoints.Subsets[i] 
for i := range ss.Ports { 
port := &ss.Ports[i] 
for i := range ss.Addresses { 
addr := &ss.Addresses 
portsToEndpoints[port 


// Ignore the protoco 





下 一 步 ， 针 对 portsToEndpoints 进 行 循环 处 理 。 对 于 每 个 记录 ， 判 断 
是 否 已 经 在 services 中 存在 ， 并 做 出 相应 的 更 新 或 跳 过 的 逻辑 ， 最 后 市 
除 那些 己 经 不 在 集合 中 的 端口 ， 完 成 整个 同步 逻辑 。 下 面 是 相关 代码 : 


for portname := range portsToEndpoints { 
svcPort := ServicePortName{types.Name 
state, exists := lb.services[svcPort ] 
curEndpoints := []string{} 
if state != nil { 
curEndpoints = state.endpoint: 


} 
newEndpoints := flattenValidEndpoints 


if !exists || state == nil || len(cur 
glog.V(1).Infof("LoadBalancer 


lb.updateAffinityMap(svcPort, 


// OnUpdate can be called wit 
// To be safe we will call it 
// if one does not already ex 
// later, once NewService is | 
state = lb.newServiceInternal 


state.endpoints = slice.Shuff 


// Reset the round-robin inde 


state.index = 0 


} 
registeredEndpoints[svcPort] = true 
} 
} 
// Remove endpoints missing from the update. 
for k := range lb.services { 
if _, exists := registeredEndpoints[k]; !exis 


glog.V(2).Infof("LoadBalancerRR: Remo: 


delete(lb.services, k) 


LoadBalancerRR 的 代码 总 体 来 说 还 是 比较 简单 的 ， 它 主要 被 kube- 
proxy 中 的 关键 组 件 proxy.Proxier 所 使 用 ， 后 者 用 到 的 主要 数据 结构 为 
proxy.serviceInfo， 它 定义 和 保存 了 一 个 Service 的 代理 过 程 中 的 必要 参数 
和 对 象 。 下 面 是 其 定义 : 





type serviceInfo struct { 


portal portal 


protocol api.Protocol 
proxyPort int 

socket proxySocket 
timeout time.Duration 
nodePort int 


loadBalancerStatus api.LoadBalancerStatus 
sessionAffinityType api.ServiceAffinity 
stickyMaxAgeMinutes int 

// Deprecated, but required for back-compat (includin 


deprecatedPublicIPs []string 


serviceInfo 的 各 个 属性 解释 如 下 。 


portal: 用 于 存放 服务 的 Portal 地 址 ， 即 Service 的 ClusterIP (VIP) 地 
址 与 端口 。 

protcal: 服务 的 TCP， 目 前 是 TCP 与 UDP。 

socket. proxyPort: socket 是 Proxier 在 本 机 上 为 该 服务 打开 的 代理 
Socket; proxyPort 则 是 这 个 代理 Socket 的 监听 端口 。 

timeout: 目前 只 用 于 UDP 的 Service， 表 明 服 务 “ 链 接 ” 的 超时 时 间 。 
nodePort: 该 服务 定义 的 NodePort。 

loadBalancerStatus: 在 Cloud 环 境 下 ， 如 果 存 在 由 Cloud 服 务 提供 者 
提供 的 负载 均衡 器 (软件 或 硬件 ) 用 作 Kubernetes Service 的 负载 均 
衡 ， 则 这 里 存放 这 些 负 载 均衡 器 的 IP 地 址 。 

sessionAffinityType: 该 服务 的 负载 均衡 调度 是 否 保持 会 话 。 
stickyMaxAgeMinutes: 即 前 面 说 的 Session 过 期 时 间 。 





e deprecatedPublicIPs: 已 过 期 、 废 弃 的 服务 的 Public IP 地 址 。 


理解 了 serviceInfo， 我 们 再 来 看 Proxier 的 数据 结构 : 


type Proxier struct { 
loadBalancer LoadBalancer 
mu sync.Mutex // protects serviceMap 
serviceMap map[ServicePortName]*serviceInfo 
portMapMutex sync.Mutex 
portMap map[portMapKey ]ServicePortName 


numProxyLoops int32 


listenIP net.IP 
iptables iptables.Interface 
hostIP net.IP 


proxyPorts PortAllocator 


Proxier 用 一 个 Map 维 护 了 每 个 服务 的 serviceInfo 信 息 ， 同 时 为 了 快 
速 查询 和 检测 服务 端口 是 否 有 冲突 ， 比 如 定义 了 两 个 一 样 问 口 的 服务 ， 
又 设计 了 一 个 portMap， 其 Key 为 服务 的 端口 信息 (portMapKey 由 port 和 
protocol 组 合 而 成 ) ，value 为 ServicePortName。Proxier 的 listenIP 为 
Proxier 监 听 的 本 节点 卫 ， 它 在 这 个 IP 上 接收 请 求 并 做 转发 代理 。 由 于 每 
个 服务 的 proxySocket 在 本 节点 监听 的 Port 诺 口 默认 是 系统 随机 分 配 的 ， 
所 以 使 用 PortAllocator 来 分 配 这 个 端口 。 另 外 ，Service 的 Portal 与 
NodePort 是 通过 Linux 防 火 增 机 制 来 实现 的 ， 因 此 这 里 引用 了 Iptables 的 
组 件 完成 相关 操作 。 








要 想 理解 Proxier 中 使 用 Iptables 的 方式 ， 首 先 我 们 要 和 弄 明 白 


Kubernetes 中 Service 访 问 的 一 些 网 络 细节 。 先 来 看 看 图 6.9， 这 是 一 个 外 
部 应 用 通过 NodePort (TCP: /NodeIP: NodePort) 来 访问 Service 时 的 网 
络 流量 示意 图 。 访 问 流 量 进 入 节点 网 卡 eth0 后 ， 到 达 Iptables 的 
PREROUTING 链 ， 通 过 KUBE-NODEPORT-CONTAINER 这 个 NAT 规 则 
被 转发 到 kube-proxy 进 程 上 该 Service 对 应 的 Proxy 端 口 ， 然 后 由 kube- 
proxy 进 程 进行 负载 均衡 并 且 将 流量 转发 到 Service 所 在 Container 的 本 地 
端口 。 


public Client 







TCP: //NodeIP:NodePort 


Switch 






PREROUTING 


OUTPUT = 


iptables 


Kube-proxy 





图 6.9 ”外 部 应 用 通过 NodePort 访 问 Service 的 网 络 流 量 示 
意图 


根据 Iptables 的 机 制 ， 本 地 进程 发 起 的 流量 会 经 过 Iptables 的 
OUTPUT 链 ， 于 是 kube-proxy 在 这 里 也 增加 了 相同 作用 的 NAT 规 则 : 


KUBE-NODEPORT-HOST。 这 样 一 来 ， 如 果 本 地 容器 内 的 进程 以 
NodePort 方 式 来 访问 Service， 则 流量 也 会 被 转发 到 kube-proxy 上 ， 虽 然 
以 这 种 方式 访问 的 情况 比较 少见 。 


服务 之 间 通 过 Service Portal 方式 访问 的 流量 转 友 机 制 跟 NodePort 方 
式 在 本 质 上 是 一 样 的 ， 也 是 通过 NAT， 如 图 6.10 所 示 。 当 Service ”A 用 
Service B 的 Portal 地 址 去 访问 时 ， 流 量 经 过 Iptables 的 OUTPUT 链 经 NAT 
规则 KUBE-PORTALS-HOST 的 转换 被 转发 到 kube-proxy 上 ， 然 后 被 转发 
给 Service B 所 在 的 容器 。 


docker0 





图 6.10 ”以 Service Portal 方 式 访问 Service 的 流量 示意 图 


Proxier 在 创建 Iptables 的 PREROUTING 链 中 的 NAT 转 发 规则 时 ， 有 
一 些 特殊 性 ， 源 码 作 者 在 代码 中 做 了 如 下 注释 : 


“这 是 一 个 复杂 的 问题 。 





如 果 Proxy 的 Proxier.listenIP 设 置 为 0.0.0.0， 即 绑 定 到 所 有 端口 上 ， 


那么 我 们 采用 REDIRECT 这 种 方式 进行 流量 转发 ， 因 为 这 种 情况 下 ， 返 
回 的 流量 与 进入 的 流量 使 用 同一 个 网 络 端口 ， 这 就 满足 了 NAT 的 规则 。 
其 他 情况 则 采用 DNAT 转 发 流量 ， 但 DNAT 到 127.0.0.1 时 ， 流 量 会 消 
失 ， 这 似乎 是 Iptables 的 一 个 众所周知 的 问题 ， 所 以 这 里 不 允许 Proxy 绑 
定 到 localhost 上。” 





现在 再 看 下 面 这 上 段 代 码 束 容易 理解 了 ， 用 来 生成 KUBE- 
NODEPORT-CONTAINER 这 条 NAT 规 则 : 


func (proxier *Proxier) iptablesContainerNodePortArgs(no 
args := iptablesCommonPortalArgs(nil, nodePort, proto 
if proxyIP.Equal(zeroIPv4) || proxyIP.Equal(zeroIPv6é) 
// TODO: Can we REDIRECT with IPv6 
args = append(args, "-j", "REDIRECT", "--to-p 
} else { 
// TODO: Can we DNAT with IPv6 
wij") "DNAT", “--to-destil 


args = append(args, 


} 


return args 





卉 明日 Proxier 中 关于 Iptables 的 事情 之 后 ， 我 们 来 研究 分 析 下 Proxier 
如 何在 OnUpdate 方 法 里 为 每 个 Service 建 立 起 对 应 的 Proxy 并 完成 同步 工 
作 。 首 先 ， 在 OnUpdate 方 法 里 创建 一 个 map CactiveServices) 来 标识 当 
前 所 有 alive 的 Service，key 为 ServicePortName， 然 后 对 OnUpdate 参 数 里 
的 Service 数 组 进行 循环 ， 判 断 每 个 Service 是 否 需要 进行 新 建 、 变 更 或 者 
删除 操作 ， 对 于 需要 新 建 或 者 变更 的 Service， 先 用 PortAllocator 获 取 一 








个 新 的 未 用 的 本 地 代理 端口 ， 然 后 调用 addServiceOnPort 方 法 创建 一 个 
ProxySocket 用 于 实现 此 服务 的 代理 ， 接 着 调用 openPortal 方 法 添加 
iptables 里 的 NAT 映 射 规则 ， 最 后 调用 LoadBalancer 的 NewService 方 法 把 
该 服务 添加 到 负载 均衡 器 上 。OnUpdate 方 法 的 最 后 一 段 逻 辑 是 处 理 已 经 
被 删除 的 Service， 对 于 每 个 要 被 删除 的 Service， 先 删除 Iptables 中 相关 的 
NAT 规 则 ， 然 后 关闭 对 应 的 proxySocket， 最 后 释放 ProxySocket 占 用 的 
监听 端口 并 将 该 端口 “还 给 ”PortAllocator。 


从 上 面 的 分 析 中 ， 我 们 看 到 addServiceOnPort 是 Proxier 的 核心 方法 
之 一 。 下 面 是 该 方法 的 源码 : 


func (proxier *Proxier) addServiceOnPort(service Service 
sock, err := newProxySocket(protocol, proxier.listen 
if err != nil { 
return nil, err 
} 
_, portStr, err := net.SplitHostPort(sock.Addr().Str 
if err != nil { 
sock.Close() 
return nil, err 
} 
portNum, err := strconv.Atoi(portStr) 
if err != nil { 
sock.Close() 
return nil, err 
} 


si := &serviceInfo{ 


proxyPort: portNum, 


protocol: protocol, 
socket: sock, 
timeout: timeout, 


sessionAffinityType: api.ServiceAffinityNone, // 
stickyMaxAgeMinutes: 180, // 
} 


proxier.setServiceInfo(service, si) 


glog.V(2).Infof("Proxying for service %q on %s port : 

go func(service ServicePortName, proxier *Proxier) { 
defer util.HandleCrash() 
atomic.AddInt32(&proxier.numProxyLoops, 1) 
sock.ProxyLoop(service, si, proxier) 
atomic.AddInt32(&proxier.numProxyLoops, -1) 


}(service, proxier) 


return si, nil 


在 上 述 代 码 中 ， 先 创建 一 个 ProxySocket， 然 后 创建 一 个 serviceInfo 
并 添加 到 Proxier 的 serviceMap 中 ， 最 后 局 动 一 个 协 程 调用 ProxySocket 的 
ProxyLoop 方 法 ， 使 得 ProxySocket 进 入 Listen 状 态 ， 开 始 接收 并 转发 客户 
in TA OR o 


kube-proxy 中 的 ProxySocket 有 两 个 实现 ， 其 中 一 个 是 
tcpProxySocket， 另 外 一 个 是 udpProxySocket， 二 者 的 工作 原理 都 一 样 ， 


它们 的 工作 流程 就 是 为 每 个 客户 端 Socket 请 求 创 建 一 个 到 Service 的 后 站 
Socket 连 接 ， 并 有 昌 “ 打 通 ” 这 两 个 Socket， 即 把 客户 端 Socket 发 来 的 数 
据 “ 复 制 *” 到 对 应 的 后 端 Socket 上， 然后 把 后 端 Socket 上 服务 啊 应 的 数据 
写 入 客户 端 Socket 上 去 。 





以 tcpProxySocket 为 例 ， 我 们 先 看 看 它 是 如 何 完成 Service 后 端 连 接 
创建 过 程 的 : 


func tryConnect(service ServicePortName, srcAddr net ,Add 


for _, retryTimeout := range endpointDialTimeout { 
endpoint, err := proxier.loadBalancer .NextEnd 
if err != nil { 


glog.Errorf("Couldn't find an endpoin 


return nil, err 


} 

glog.V(3).Infof("Mapped service %q to endpoin 
outConn, err := net.DialTimeout(protocol, end 
if err != nil { 


if isTooManyFDsError(err) { 
panic("Dial failed: " + err.E 

} 

glog.Errorf("Dial failed: %v", err) 

continue 


} 


return outConn, nil 


} 


return nil, fmt.Errorf("failed to connect to an endpo 


在 上 述 方法 里 ， 首 先 调用 loadBalancer.NextEndpoint 方 法 获取 服务 的 
下 一 个 可 用 Endpoint 地 址 ， 然 后 调用 标准 网 络 库 中 的 方法 建立 到 此 地 址 
的 连接 ， 如 果 连 接 失 败 ， 则 会 重新 答 试 ， 间 隔 时 间 指 数 增加 《参见 
endpointDialTimeout 的 值 ) 。 





在 后 端 Service 的 连接 建立 以 后 ，proxyTCP 方 法 就 会 局 动 两 个 协 程 ， 
通过 调用 Go 标准 库 io 里 的 Copy 方 法 把 输入 流 的 数据 写 入 输出 流 ， 从 而 完 
成 前 后 端 连接 的 数据 转发 功能 。 此 外 ，proxyTCP 方 法 会 阻塞 ， 直 到 前 后 
端 两 个 连接 的 数据 流 都 关闭 〈 或 结束 ) 才 会 返回 。 下 面 是 其 源码 : 


func proxyTCP(in, out *net.TCPConn) { 

var wg sync.WaitGroup 

wg .Add(2) 

glog.V(4).Infof("Creating proxy between %v <-> %v <-> 
in.RemoteAddr(), in.LocalAddr(), out.LocalAdd 

go copyBytes("from backend", in, out, &wg) 

go copyBytes("to backend", out, in, &wg) 

wg .Wait() 

in.Close() 


out.Close() 


这 里 我 们 留 一 个 问题 ，kube-proxy 会 在 当前 节点 上 为 每 个 Service 都 
建立 一 个 代理 么 ? 不 管 本 节点 上 是 否 有 该 Service 对 应 的 Pod? 





6.6.3 ”设计 上 总结 


从 之 前 的 局 动 流程 和 代码 分 析 来 看 ，kube-proxy 的 设计 和 实现 还 是 
比较 精巧 和 紧凑 的 ， 它 的 流程 只 有 一 个 : 从 Kubernetes API Server 上 同 
步 Service 及 其 Endpoint 信 息 ， 为 每 个 Service 建 立 一 个 本 地 代理 以 完成 具 
备 负 和 载 均衡 能 力 的 服务 转发 功能 。 图 6.11 给 出 了 kube-proxy 的 总 体 设 计 
示意 图 ， 为 了 清晰 地 表明 整个 业务 流程 和 数据 传递 方向 ， 这 里 省 去 了 一 
些 非 关键 的 结构 体 和 对 象 。app.ProxyServer 创 建 了 一 个 config.SourceAPI 
的 结构 体 ， 用 于 拉 取 Kubernetes API Server 上 的 Service 与 Endpoint 配 置信 
ik, 2%!) Fconfig.servicesReflectorSconfig.endpointsReflectoriX P§ XT KR 
来 实现 ， 它 们 各 自 通过 相应 的 Kubernetes Client API 来 拉 取 数据 并 且 生 成 
对 应 的 Update 信 息 放 入 Channel 中 ， 最 终 Channel 中 的 Service 数 据 到 达 
proxy.Proxier 上 ，proxy.Proxier 为 每 个 Service 建 立 一 个 proxySocket 实 现 服 
务 代理 并 且 在 iptables 上 创建 相关 的 NAT 规 则 ， 然 后 在 LoadBalancer 组 件 
上 开通 该 服务 的 负载 均衡 功能 ， 而 Channel 中 的 Endpoints 数 据 则 被 发 送 
到 proxy.LoadBalancerRR 组 件 ， 用 于 给 每 个 服务 建立 一 个 负载 均衡 的 状 
态 机 ， 每 个 服务 用 banlancerState 结 构 体 来 保存 该 服务 可 用 的 Endpoint 地 
址 及 当前 的 会 话 状 态 affinityPolicy， 对 于 需要 保存 会 话 状态 的 服务 ， 
affinityPolicy 用 一 个 Map 来 存储 每 个 客户 的 会 话 状态 affinityState。 

















图 6.11 与 kubelet 总 体 相 关 的 设计 示意 图 


6.7 ”kubectl 进 程 源码 分 析 


kubect 与 之 前 的 Kubernetes 进 程 不 同 ， 它 不 是 一 个 后 台 运 行 的 守护 
进程 ， 而 是 Kubernetes 提 供 的 一 个 命令 行 工 具 〈CLI) ， 它 提供 了 一 组 命 
令 来 操作 Kubernetes 集 群 。 


kubectl 进 程 的 入 口 类 源码 位 置 如 下 : 
github/com/GoogleCloudPlatform/kubernetes/cmd/kubect1l/ku 
入 口 main() 函数 的 逻辑 很 简单 : 


func main() { 


runtime .GOMAXPROCS( runtime .NumCPU( ) ) 


cmd := cmd.NewKubect1lCommand(cmdutil.NewFactory(nil), os 
if err := cmd.Execute(); err != nil { 

os.Exit(1) 

} 

} 


上 述 代码 通过 NewKubectlCommand 方 法 创建 了 一 个 具体 的 
Command 命 令 并 调用 它 的 Execute 方 法 执行 ， 这 是 工厂 模式 结合 命令 模 
式 的 一 个 经 典 设计 案例 。 从 NewKubectlCommand 的 源码 中 可 以 看 到 ， 
kubectl 的 CLI 命 令 框架 使 用 了 GitHub 开 源 项 目 

Chttps://github.com/spf13/cobra) ， 下 面 是 该 框架 中 对 Command 的 定 


type Command struct { 
Use string // The one-line usage message. 
Short string // The short description shown in the '| 
Long string // The long message shown in the 'help < 


Run func(cmd *Command, args []string) // Run runs thi 


实现 一 个 具体 Command 就 只 要 实现 Command 的 Run 函 数 即 可 ， 下 面 
是 其 官方 网 页 给 出 的 一 个 Echo 命 令 的 例子 : 





var cmdEcho = &cobra.Command{ 
Use: "echo [string to echo]", 
Short: "Echo anything to the screen", 
Long: “echo is for echoing anything back. 
Echo works a lot like print, except it has a chi 


了 


Run: func(cmd *cobra.Command, args []string) { 


fmt.Printlin("Print: " + strings.Join(args, 


ty 


由 于 大 多 数 kubectl 的 命令 都 需要 访问 Kubernetes API Server， 上 所 以 
kubectl 设 计 了 一 个 类 似 命令 的 上 下 文 环境 的 对 象 
Command 对 象 使 用 。 





util.Factory 供 


在 接 下 来 的 几 个 章节 中 ， 我 们 对 kubectl 中 的 几 个 典型 Command 的 源 
码 逐 一 解读 。 


6.7.1 kubectl create 命 令 


kubectl create 命令 通过 调用 Kubernetes API Server 提 供 的 RestAPI 来 
创建 Kubernetes 资 源 对 象 ， 例 如 Pod、Service、RC 等 ， 资 源 的 描述 信息 
来 目 -{f 指 定 的 文件 或 者 来 自命 令 行 的 输入 流 。 下 面 是 创建 create 命 令 的 相 
天 源码 : 





func NewCmdCreate(f *cmdutil.Factory, out io.Writer) *co 


var filenames util.StringList 


cmd := &cobra.Command{ 
Use: "create -f FILENAME", 
Short: "Create a resource by filename or st 
Long: create_long, 


Example: create_example, 

Run: func(cmd *cobra.Command, args []string) 
cmdutil.CheckErr(ValidateArgs(cmd, ar 
cmdutil.CheckErr(RunCreate(f, out, fi. 

ty 

} 


usage := "Filename, directory, or URL to file to use 
kubectl.AddJsonFilenameFlag(cmd, &filenames, usage) 
cmd.MarkFlagRequired("filename" ) 


return cmd 


AddJsonFilenameFlag 方 法 限制 flename 参 数 〈-f) 的 文件 名 后 级 只 能 
是 json、yaml 或 者 yml 中 的 一 种 ， 并 且 将 参数 值 填充 到 科 enames 这 个 Set 
集合 中 ， 随 后 被 Command 的 Run 函 数 中 的 RunCreate 方 法 所 引用 ， 后 者 束 
是 kubectl create 命 令 的 核心 逻辑 所 在 。 


RunCreate 方 法 使 用 到 了 resource.Builder 对 象 ， 它 是 kubectl 中 的 一 处 
复杂 设计 ， 采 用 了 Visitor 的 设计 模式 ，kubectl 的 很 多 命令 都 用 到 了 它 。 
Builder 的 目标 是 根据 命令 行 输入 的 资源 相关 的 参数 ， 创 建 针 对 性 的 
Visitor 对 象 来 获取 对 应 的 资源 ， 最 后 遍历 相关 的 所 有 Visitor 对 象 ， 触 发 
用 户 指定 的 VisitorFun 回 调 函 数 来 处 理 每 个 具体 的 资源 ， 最 终 完成 资源 
对 象 的 业务 处 理 逻 辑 。 由 于 涉及 的 资源 参数 有 各 种 情况 ， 所 以 导致 
Builder 的 代码 很 复杂 。 以 下 是 Builder 所 能 操作 的 各 种 资源 参数 : 





。 通过 输入 法 提 供 具 体 的 资源 描述 ; 

。 通过 本 地 文件 内 容 或 者 HTTP URL 的 输出 流 来 获取 资源 描述 ; 

。 文件 列表 提供 多 个 资源 描述 ; 

指定 资源 类 型 ， 通 过 查询 Kubernetes API Server 来 获取 相关 类 型 的 
资源 ; 

指定 资源 的 selector 条 件 如 cluster-service=true， 查 询 Kubernetes API 
Server 来 获取 相关 的 资源 ; 

指定 资源 的 namespace 来 查询 符合 条 件 的 相关 资源 。 


下 面 是 resource.Builder 的 定义 : 


type Builder struct { 
mapper *Mapper 
errs []error 


paths []Visitor 


stream bool 

dir bool 

selector labels.Selector 
selectAll bool 

resources []string 
namespace string 

names [ ]string 
resourceTuples []resourceTuple 
defaultNamespace bool 
requireNamespace bool 
flatten bool 

latest bool 
requireObject bool 
SingleResourceType bool 
continueOnError bool 


schema validation.Schema 


其 实 Builder 很 像 一 个 SQL 碍 询 条 件 的 生成 器 ， 里 面包 括 了 各 种 “得 
询 ” 条 件 ， 在 指定 不 同 的 查询 条 件 时 ， 会 生成 不 同 的 Visitor 接 口 来 处 理 
这 些 查 询 条 件 ， 最 后 遍历 所 有 Visitor， 就 得 到 最 终 的 “查询 结果 ”。 
Builder 返 回 的 Result 对 象 里 也 包括 Visitor 对 象 及 可 能 的 最 终 资源 列表 等 
言 思 ， 由 于 资源 得 询 存 在 各 种 情况 ， 所 以 Result 也 提供 了 多 种 方法 ， 比 
如 还 包括 了 Watch 资源 变化 的 方法 。 


RunCreate 方 法 里 先 创建 了 一 个 Builder， 设 置 各 种 必要 参数 ， 然 后 
调用 Builder 的 Do 方法 ， 返 回 一 个 Result， 代 码 如 下 : 


schema, err := f.Validator() 
mapper, typer := f.Object() 
r := resource.NewBuilder(mapper, typer, f.ClientMappe 

Schema(schema) . 
ContinueOnError(). 
NamespaceParam(cmdNamespace) .DefaultNamespace 
FilenameParam(enforceNamespace, filenames...) 
Flatten(). 
Do() 


FLA, schema RAR Beye ot VFA Ae A EBA, UAA hb 
段 或 者 属性 的 类 型 错误 等 mapper 对 象 用 来 完成 从 资源 描述 信息 到 资源 
对 象 的 转换 ， 用 来 在 REST 调 用 过 程 中 完成 数据 转换 ;，FilenameParam 是 
这 里 唯一 指定 Builder 的 资源 参数 的 方法 ， 即 把 命令 行 传 入 的 fenames 参 
数 作 为 资源 参数 ;Flatten 方 法 则 告诉 Builder， 这 里 的 资源 对 象 其 实 是 一 
个 数组 ， 需 要 Builder 构 造 一 个 FlattenListVisitor 来 遍历 Visit 数 组 中 的 每 个 
资源 项 目 ; Do 方法 则 返回 一 个 Rest 对 象 ， 里 面包 括 与 资源 相关 的 Visitor 
对 象 。 





下 面 是 NamespaceParam 方 法 的 源码 ， 主 要 逻辑 为 调用 Builder 的 
Builder.Stdin、Builder.URL 或 Builder.Path 方 法 来 处 理 不 同类 型 的 资源 参 
数 ， 这 些 方法 会 生成 对 应 的 Visitor 对 象 并 加 入 Builder 的 Visitor 数 组 里 

(paths 属 性 〉。 


func (b *Builder) FilenameParam(enforceNamespace bool, p 
for _, s := range paths { 


switch { 


case s == "-"; 


b.Stdin() 
case strings.Index(s, "http://") == 0 || strings.Index(s 
url, err := url.Parse(s) 
if err != nil { 


b.errs = append(b.errs, fmt.Errorf("the URL passed to fi 

continue 

} 

b.URL(ur1) 

default: 

b.Path(s) 

} 

} 


if enforceNamespace { 


b.RequireNamespace( ) 


} 


return b 


} 





不 管 是 标准 输入 流 、URL， 还 是 文件 目录 或 者 文件 本 身 ， 这 里 处 理 
资源 的 Visitor 都 是 StreamVisitor 这 个 实现 (FileVisitor 与 
FileVisitorForSTDIN 是 StreamVisitor 的 一 个 Wrapper) > F HÆ 
StreamVisitor 的 Visit 接 口 代码 : 


func (v *StreamVisitor) Visit(fn VisitorFunc) error { 
d := yaml.NewYAMLOrJSONDecoder(v.Reader, 4096) 
for { 


ext := runtime.RawExtension{} 
if err := d.Decode(&ext); err != nil { 
if err == 10.E0F { 


return nil 


} 
return err 

} 

ext.RawJSON = bytes.TrimSpace(ext.RawJSON) 

if len(ext.RawJSON) == || bytes.Equal(ext.RawJ: 
continue 

} 

if err := ValidateSchema(ext.RawJSON, v.Schema); 


return err 


} 
info, err := v.InfoForData(ext.RawJSON, v.Source 
if err != nil { 
if v.IgnoreErrors { 
fmt.Fprintf(os.Stderr, "error: could not 
glog.V(4).Infof("Unreadable: %s", string 
continue 
} 
return err 
} 
if err := fn(info); err != nil { 


return err 


在 上 述 代码 中 ， 上 前 先 从 输入 流 中 解析 具体 的 资源 对 象 ， 然 后 创建 一 
个 Info 结 构 体 进行 包装 (转换 后 的 资源 对 象 存 储 在 Info 的 Object 属 性 
中 ) ， 最 后 再 用 这 个 Info 对 象 作 为 参数 调用 回调 函数 VisitorFunc， 从 而 
完成 整个 逻辑 流程 。 下 面 是 RunCreate 方 法 里 调用 Builder 的 Visit 方 法 触 
发 Visitor 执 行 时 的 源码 ， 可 以 看 到 这 里 的 VisitorFunc 所 做 的 事情 是 通过 
Rest Client 发 起 Kubernetes API 调 用 ， 把 资源 对 象 写 入 资源 注册 表 里 : 


err 


}) 


r.Visit(func(info *resource.Info) error { 


data, err := info.Mapping.Codec.Encode(info.Obje 
if err != nil { 


return cmdutil.AddSourceToErr("creating", in 


} 
obj, err := resource.NewHelper(info.Client, info 
if err != nil { 

return cmdutil.AddSourceToErr("creating", in 
} 
count++ 


info.Refresh(obj, true) 
printObjectSpecificMessage(info.Object, out) 
fmt.Fprintf(out, "%s/%s\n", info.Mapping.Resourc 


return nil 


6.7.2 rolling-update 命 令 


kubectl rolling-update 命 令 负责 滚动 更 新 〈 升 级 ) 
RC (ReplicationController) ， 下 面 是 创建 对 应 Command 的 源码 : 


func NewCmdRollingUpdate(f *cmdutil.Factory, out io.Writ' 
cmd := &cobra.Command{ 

Use: "rolling-update OLD_CONTROLLER_NAME ([NE\ 

// rollingupdate is deprecated. 

Aliases: []string{"rollingupdate"}, 

Short: "Perform a rolling update of the giv 

Long: rollingUpdate_long, 

Example: rollingUpdate_example, 

Run: func(cmd *cobra.Command, args []string) 
err := RunRollingUpdate(f, out, cmd, | 
cmdutil.CheckErr(err) 

ty 

} 
cmd.Flags().String("update-period", updatePeriod, “Til 


此 处 省 去 一 些 命令 参数 添加 的 非 关 键 代 码 : 


cmdutil.AddPrinterFlags(cmd) 


return cmd 


从 上 述 代 码 中 我 们 看 到 rolling-update 命 令 的 执行 函数 为 
RunRollingUpdate， 在 分 析 这 个 函数 之 前 ， 我 们 先 了 解 下 rolling-update 
执行 过 程 中 的 一 个 关键 逻辑 。 


rolling update 动 作 可 能 由 于 网 络 超 时 或 者 用 户 等 得 不 耐烦 等 原因 被 
中 断 ， 因 此 我 们 可 能 会 重复 执行 一 条 rolling-update 命 令 ， 目 的 只 有 一 
个 ， 束 是 恢复 之 前 的 rolling update 动 作 。 为 了 实现 这 个 目的 ，rolling- 
update 程 序 在 执行 过 程 中 会 在 当前 rolling-update 的 RC 上 增加 一 个 
Annotation 标 签 一 一 kubectl.kubernetes.io/next-controller-id， 标 签 的 值 就 
是 下 一 个 要 执行 的 新 RC 的 名 字 。 此 外 ， 对 于 Image 升 级 这 种 更 新 方式 ， 
还 会 在 RC 的 Selector 上 (RC.Spec.Selector〉 贴 一 个 名 为 deploymentKey 的 
Label，Label 的 值 是 RC 的 内 容 进行 Hash 计 算 后 的 值 ， 相 当 于 签名 ， 这 样 
就 能 很 方便 地 比较 RC 里 的 Image 名 字 ( 以 及 其 他 信息 ) 是 否 发 生 了 变 
化 8 

















RunRollingUpdate 执 行 逻辑 的 第 1 步 : 确定 New RC 对 象 及 建立 起 Old 
RC 到 New RC 的 关联 关系 。 下 面 我 们 以 指定 的 Image 参 数 进 行 rolling 
update 的 方式 为 例 ， 看 看 代码 是 如 何 实现 这 段 逻 辑 的。 下 面 是 相关 源 
码 : 


if len(image) != © { 
keepOldName = len(args) == 1 
newName := findNewName(args, oldRc) 
if newRc, err = kubectl.LoadExistingNextRepli 
return err 


} 


if newRc != nil { 


fmt.Fprintf(out, "Found existing upda 
} else { 

newRc, err = kubectl.CreateNewControl. 

if err != nil { 


return err 


} 

// Update the existing replication controller 
// and adding the <deploymentkey> label if ne 
oldHash, err := api.HashObject(oldRc, client.| 
if err != nil { 

return err 

} 

oldRc, err = kubectl.UpdateExistingReplicatio 
if err != nil { 


return err 


在 代码 里 ，findNewName 方 法 查询 新 RC 的 名 字 ， 如 果 在 命令 行 参 
数 中 没有 提供 新 RC 的 名 字 ， 则 从 Old RC 中 根据 
kubectl.kubernetes.io/next-controller-id 这 个 Annotation 标 签 找 新 RC 的 名 字 
并 返回 ， 如 果 新 RC 存 在 则 继续 使 用 ， 人 否则 调用 
CreateNewControllerFromCurrentController 方 法 创建 一 个 新 RC， 在 新 RC 
的 创建 过 程 中 设 定 deploymentKey 的 值 为 自己 的 Hash 签 名 ， 方 法 源码 如 
Re: 


func CreateNewControllerFromCurrentController(c *client.' 
// load the old RC into the "new" RC 
newRc, err := c.ReplicationControllers(namespace).Get 
if err != nil { 

return nil, err 
} 
if len(newRc.Spec.Template.Spec.Containers) > 1 { 

// TODO: support multi-container image update 
return nil, goerrors.New("Image update is not support: 
} 
if len(newRc.Spec.Template.Spec.Containers) == 0 { 


return nil, goerrors.New(fmt.Sprintf("Pod has 


} 

newRc.Spec.Template.Spec.Containers[@].Image = image 
newHash, err := api.HashObject(newRc, c.Codec) 

if err != nil { 


return nil, err 


} 
if len(newName) == © { 

newName = fmt.Sprintf("%s-%s", newRc.Name, ne 
} 


newRc ,Name = newName 
newRc.Spec.Selector[deploymentKey] = newHash 
newRc.Spec.Template.Labels[deploymentKey] = newHash 
// Clear resource version after hashing so that ident. 


newRc.ResourceVersion = "" 


return newRc, nil 


在 Image rolling update 的 流程 中 确定 新 的 RC 以 后 ， 调 用 
UpdateExistingReplicationController 方 法 ， 将 旧 RC 的 
kubectl.kubernetes.io/next-controller-id 设 置 为 新 RC 的 名 字 ， 并 且 判 断 旧 
RC 是 否 需要 设置 或 更 新 deploymentKey， 有 具体 代码 如 下 : 


func UpdateExistingReplicationController(c client.Interfi 
SetNextControllerAnnotation(oldRc, newName) 
if _, found := oldRc.Spec.Selector[deploymentKey]; ! fi 
return AddDeploymentKeyToReplicationControlle 
} else { 
// If we didn't need to update the controller for the 
// the "next" controller. 


return c.ReplicationControllers(namespace) .Upi 


通过 上 面 的 逻辑 ， 新 RC 被 确定 并 且 旧 RC 到 新 RC 的 关联 关系 也 被 建 
立 好 了 ， 接 下 来 如 果 dry-run 参 数 为 tue， 则 仅仅 打印 新 肯 RC 的 信息 然后 
返回 。 如 果 是 正常 的 rolling update 动 作 ， 则 创建 一 个 
kubectl.RollingUpdater 对 象 来 执行 具体 任务 ， 任 务 的 参数 则 放 在 
kubectl.RollingUpdaterConfig 中 ， 相 关 源 码 如 下 : 


updateCleanupPolicy := kubectl.DeleteRollingUpdateCleanu 
if keepOldName { 


updateCleanupPolicy = kubectl.RenameRollingUp 


} 

config := &kubectl.RollingUpdaterConfigf{ 
Out: out, 
OldRc: oldRc, 
NewRc: newRc, 


UpdatePeriod: period, 
Interval: interval, 
Timeout: timeout, 


CleanupPolicy: updateCleanupPolicy, 


其 中 out 是 输出 流 《〈 屏 幕 输出 ) ; UpdatePeriod 是 执行 rolling update 
动作 的 间隔 时 间 ; Interval 与 Timeout 组 合 使 用 ， 前 者 是 每 次 拉 取 polling 
controller 状 态 的 间隔 时 间 ， 而 后 者 则 是 对 应 的 HTTP REST 调 用 ) 超时 
时 间 。CleanupPolicy 确 定 升 级 结束 后 的 善后 策略 ， 比 如 
DeleteRollingUpdateCleanupPolicy 表 示 删 除 旧 的 RC， 而 
RenameRollingUpdateCleanupPolicy 则 表示 保持 RC 的 名 字 不 变 〈 改 变 新 
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RollingUpdaterf Update 7y 7 é rolling update 的 核心 ， 它 以 上 述 
config 对 象 作 为 参数 ， 其 核心 流程 是 每 次 让 新 RC 的 Pod 副 本 数量 加 1， 同 
时 旧 RC 的 Pod 副 本 数量 减 1， 直 到 新 RC 的 Pod 副 本 数量 达到 预期 值 同时 
上 日 RC 的 Pod 副 本 数量 变 为 零 为 止 ， 在 这 个 过 程 中 iF RCH PodB A 
数量 一 直 在 变动 ， 所 以 需要 一 个 地 方 记录 最 初 不 变 的 那个 Pod 副 本 数 
量 ， 这 里 就 是 RC 的 Annotation 标 签 




















kubectl.kubernetes.io/desired- 


replicas 。 


下 面 这 段 源 码 就 是 “贴标签 ”的 过 程 : 


fmt.Fprintf(out, "Creating %s\n", newName) 
if newRc.ObjectMeta.Annotations == nil { 
newRc.ObjectMeta.Annotations = map[st 
} 
newRc .ObjectMeta.Annotations[desiredReplicasA 
newRc .ObjectMeta.Annotations[sourceIdAnnotati 
newRc.Spec.Replicas = 0 


newRc, err = r.c.CreateReplicationController ( 


下 面 这 段 源 码 便 是 “江山 代 有 才 人 出 ， 一 代 新 人 换 旧 人 ”的 生动 画 


for newRc.Spec.Replicas < desired && oldRc.Spec.Repli 

newRc.Spec.Replicas += 1 

oldRc.Spec.Replicas -= 

fmt.Printf("At beginning of loop: %s replicas 
oldName, oldRc.Spec.Replicas, 
newName, newRc.Spec.Replicas) 

fmt.Fprintf(out, "Updating %s replicas: %d, % 
oldName, oldRc.Spec.Replicas, 
newName, newRc.Spec.Replicas) 

newRc, err = r.scaleAndWait(newRc, retry, wal 

if err != nil { 


return err 


time.Sleep(updatePeriod) 
oldRc, err = r.scaleAndWait(oldRc, retry, wal 
if err != nil { 
return err 
} 
fmt.Printf("At end of loop: %s replicas: %d, ‘ 
oldName, oldRc.Spec.Replicas, 
newName, newRc.Spec.Replicas) 
} 
// delete remaining replicas on oldRc 
if oldRc.Spec.Replicas != 0 { 
fmt.Fprintf(out, "Stopping %s replicas: %d -> 
oldName, oldRc.Spec.Replicas, 0) 
oldRc.Spec.Replicas = 0 
oldRc, err = r.scaleAndWait(oldRc, retry, wal 
if err != nil { 


return err 


} 


// add remaining replicas on newRc 
if newRc.Spec.Replicas != desired { 
fmt.Fprintf(out, "Scaling %s replicas: %d -> : 
newName, newRc.Spec.Replicas, desired 
newRc.Spec.Replicas = desired 
newRc, err = r.scaleAndWait(newRc, retry, wal 
if err != nil { 


return err 


上 述 方 法 里 的 scaleAndWait 方 法 调用 了 
kubectl.ReplicationControllerScaler 的 Scale 方 法 ，Scale 方 法 先 通 过 Rest 
API 调 用 Kubernetes API Server 更 新 RC 的 Pod 副 本 数量 ， 然 后 循环 拉 取 RC 

言 上 号 ， 直 到 超时 或 者 RC 同步 状态 完成 。 下 面 是 判断 RC 同步 状态 是 否 完 
成 的 函数 ， 来 自 dient 包 (pkg/client/conditions.go) 。 


func ControllerHasDesiredReplicas(c Interface, controlle 
desiredGeneration := controller.Generation 
return func() (bool, error) { 
ctrl, err := c.ReplicationControllers(control 
if err != nil { 
return false, err 
} 


return ctrl.Status.ObservedGeneration >= desi 


rolling-update 是 kubectl 所 有 命令 中 最 为 复杂 的 一 个 ， 从 它 的 功能 和 
流程 来 看 ， 完 全 可 以 被 当 作 一 个 Job 并 放 到 kube-controller-manager 上 实 
现 ， 客 户 病 仪 仪 发 起 Job 的 创建 及 Job 状 态 查 看 等 命令 即 可 ， 未 来 
Kubernetes 的 版 本 是 否 会 这 样 重 构 ， 我 们 拭目以待 。 


后 记 


Kubernetes 无 疑 是 容器 化 技术 时 代 最 好 的 分 布 式 系统 架构 ， 但 是 目 
前 它 还 没有 一 款 很 好 的 图 形 化 管理 工具 ， 基 本 上 是 命令 行 操作 ， 因 此 不 
容易 入 门 。 另 外 ， 在 系统 运行 过 程 中 ， 我 们 难以 直观 了 解 当 前 服务 的 分 
布 情况 及 资源 的 使 用 情况 ， 日 志 也 不 完善 ， 难 以 快速 退 踪 和 排查 故障 ， 
因此 ， 我 们 发 起 了 一 个 名 为 Ku8eye 的 开源 项 目 ， 这 是 借鉴 了 OpenStack 
Horizon, Cloudera ”Manager 等 知名 软件 的 设计 思想 的 一 蒜 国 产 开源 软 
件 ， 目 标 是 成 为 Kubernetes 的 姊妹 开源 项 目 。 





Ku8eye 作 为 Kubernetes 的 一 站 式 管理 工具 ， 有 具备 如 下 关键 特性 。 


图 形 化 一 键 安装 和 部 署 多 节点 Kubernetes 集 群 。 这 是 安装 、 部 署 谷 
歌 Kubernetes 集 群 的 最 快 、 最 佳 方式 ， 其 安装 流程 会 参考 当前 的 系 
统 环 境 ， 提 供 默 认 优化 的 集群 安装 参数 ， 实 现 最 佳 部 署 。 
支持 多 角色 、 多 租户 的 Portal 管 理 界 面 。 通 过 一 个 集中 化 的 Portal 界 
面 ， 运 营 团 队 可 以 很 方便 地 调整 集群 配置 及 管理 集群 资源 ， 实 现 路 
部 门 的 角色 、 用 户 及 多 租户 管理 ， 通 过 自助 服务 可 以 很 容易 完成 
Kubernetes 集 群 的 运 维 管 理工 作 。 
制定 了 Kubernetes 应 用 的 程序 发 布 包 标 准 (ku8package) ， 并 提供 
一 款 向 导 工 具 ， 使 得 专门 为 Kubernetes 设 计 的 应 用 能 够 很 容易 地 
从 本 地 环境 发 布 到 公有 云 和 其 他 环境 中 ;并且 提供 了 Kubernetes 应 








用 的 可 视 化 构建 工具 ， 实 现 了 Kubernetes Service、RC、Pod 及 其 他 
资源 的 可 视 化 构建 和 管理 功能 。 

可 定制 化 的 监控 和 告警 系统 。Ku8eye 内 建 了 很 多 系统 健康 检查 工具 
来 检测 、 发 现 寞 第 并 触发 告警 事件 ， 不 仅 可 以 监控 集群 中 的 所 有 他 
点 和 组 件 (包括 Docker 与 Kubernetes) ， 还 可 以 很 容易 地 监控 业务 
应 用 的 性 能 ， 并 且 提 供 了 一 个 强大 的 Dashboard， 用 来 生成 各 种 复 
杂 的 监控 图 表 以 展示 历史 信息 ， 还 可 用 来 自 定 义 相关 监控 指标 的 告 
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具备 综合 的 全 面 的 故障 排查 能 力 。Ku8eye 提 供 了 集中 化 的 唯一 日 志 
管理 工具 ,日 志 系 统 从 集群 中 的 各 个 布点 拉 取 日 志 并 做 聚合 分 析 ， 
拉 取 的 日 志 包 括 系统 日 志和 用 户 程序 日 志 ; 并 且 提 供 了 全 文 检索 能 
力 以 方便 故障 分 析 和 问题 排查 ， 检 索 的 信息 包括 相关 告警 信息 ， 而 
历史 视图 和 相关 的 度量 数据 则 告诉 我 们 什么 时 候 发 生 了 什么 事情 ， 
有 助 于 快速 了 解 相关 时 间 内 系统 的 行为 特征 。 

实现 了 Docker 与 Kubernetes 项 目的 持续 集成 功能 。Ku8eye 提 供 了 一 
款 可 视 化 工具 ， 用 来 驱动 持续 集成 的 整个 流程 ， 包 括 创 建新 的 
Docker 镜 像 ，Push 镜 像 到 私有 仓库 ， 创 建 Kubernetes 测 试 环境 进行 
测试 ， 以 及 最 终 滚动 升级 到 生产 环境 中 的 各 个 主要 环节 。 











Ku8eye 的 GitHub 地 址 为 https://github.com/bestcloud，Ku8eye 目 前 所 
用 到 的 技术 包括 Java Web、Ansible 脚 本 ， 未 来 可 能 涉及 Python 脚 本 及 
Android 开 发 等 。 截 至 本 书 出 版 时 ，Ku8eye 已 有 10 多 名 团队 成 员 。 如 果 
您 有 兴趣 ， 可 在 学 完 本 书后 加 入 本 项 目 QQ 和 群 (Kubermetes H) : 
285431657。 








Invite someone 请 您 加 入 我 们 


